Bug 416 - pcap traces not always closing cleanly at simulation end
pcap traces not always closing cleanly at simulation end
Status: RESOLVED INVALID
Product: ns-3
Classification: Unclassified
Component: helpers
ns-3-dev
All All
: P1 normal
Assigned To: Craig Dowell
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-19 20:03 EST by Tom Henderson
Modified: 2008-12-03 14:59 EST (History)
2 users (show)

See Also:


Attachments
start of a patch to fix this (7.25 KB, patch)
2008-11-19 20:03 EST, Tom Henderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2008-11-19 20:03:35 EST
Created attachment 308 [details]
start of a patch to fix this

I noticed some non-deterministic output in the pcap tracing while debugging something else, and I tracked it down to the fact that the destructor for PcapWriter is not being called in most cases, and the ofstream is not being flushed and closed.  

I saw some support in InternetStackHelper for scheduling a SimulatorDestroy() event to cleanup and close these ofstreams.  However, there are two problems that I see with that particular support:
- it tries to cause the destructor to be invoked by zeroing the smart pointer, but my testing suggests that this is not sufficient (hence I added an explicit Close() method in the attached patch)
- it only covers the case when EnablePcapAll() has been selected, but not when Pcap is enabled with finer granularity.

Attached is a start of a patch to try to fix this behavior, but it would need to be extended to all NetDevices (esp. WifiNetDevice) and it would need to cover all of the entry points into Pcap tracing (rather than just EnablePcapAll()).
Comment 1 Craig Dowell 2008-11-26 15:09:18 EST
This is due to a memory leak in dynamic-global-routing.cc that causes the pcap writer destructors not to be called.

Don't know what exactly is holding references, but there is a channel cycle that makes me nervous.