[Ns-bugs] [Bug 933] Flushing ostream and files on abnormal program exit (ASSERT, ABORT and FATAL_ERROR)

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=933





--- 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
or empty

-- 
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.