[Ns-bugs] [Bug 931] Abnormal exit reports SIGSEGV on failure
code@nsnam.ece.gatech.edu
code at nsnam.ece.gatech.edu
Wed Jun 2 22:14:48 PDT 2010
http://www.nsnam.org/bugzilla/show_bug.cgi?id=931
--- Comment #22 from quincy.tse at gmail.com 2010-06-03 01:14:47 EDT ---
(In reply to comment #21)
> There seem to be two issues in this tracker item, fixing up the ASSERT, ABORT,
> FATAL_ERROR behavior, and getting streams to flush upon abnormal exit.
Agreed - it originally started as fixing the behaviour. But the proposed
solutions opened up the possibility to flushing files and streams. Maybe a
second bug should be started for the stream flushing bit and move those bits
there.
> but wouldn't it be simpler to just
> have the user toggle std::ios_base::unitbuf (or explicit flush()) on all trace
> streams when the user runs into a problematic program?
That's one option (I'm not sure about the extra IO cost - I haven't measured
it). The problem here would be that many people would just rely on streams that
are opened behind the scene (eg. ascii/pcap traces, etc). I wouldn't expect an
NS3 user would go around and tinker with someone elses' code just to get the
traces out.
> Also, wouldn't that
> option also take care of the case in which memory leaks cause traces not to be
> written upon exit? (unless missing traces are useful as a crude leak
> detector...)
By memory leak, I assume you're referring to the case when destructor was not
called? (eg. printing summary when some statistic class was destroyed) Turning
off write buffer can't help with things that have never been put into the
stream yet (ie the case I'm referring to). Also, if the program crashes,
destructors won't normally be called anyway.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the Ns-bugs
mailing list