[Ns-bugs] [Bug 933] Flushing ostream and files on abnormal program exit (ASSERT, ABORT and FATAL_ERROR)
code at nsnam.ece.gatech.edu
Wed Jun 2 23:18:16 PDT 2010
--- Comment #2 from Tom Henderson <tomh at tomh.org> 2010-06-03 02:18:15 EDT ---
Carrying over from bug 931.
> > 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.
Yes, I would suggest that the user API would be similar to how we enable
checksums (see GlobalValue g_checksumEnabled in node.cc) so that users don't
have to edit the streams opened behind the scenes.
> > 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.
when there is a leak on (non-crashing) exit, references aren't all cleared and
streams aren't flushed, with the result that pcap or ascii files are truncated
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