OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000555OMNeT++simulation kernelpublic2012-03-27 09:592012-03-27 10:07
andras 
andras 
normalminorhave not tried
resolvedfixed 
4.2.1 
4.2.2 
0000555: Memory leak in output vector recording
Output vectors leak memory when they are destroyed. This causes problems for simulations that continuously create new output vectors at runtime -- their process size will inflate. A workaround is to set per-vector buffer limit to the minimum (1).

Reported by David Eckhoff.
No tags attached.
patch omnetpp.patch (986) 2012-03-27 10:07
https://dev.omnetpp.org/bugs/file_download.php?file_id=94&type=bug
patch vector.patch (1,731) 2012-03-27 10:07
https://dev.omnetpp.org/bugs/file_download.php?file_id=95&type=bug
Issue History
2012-03-27 09:59andrasNew Issue
2012-03-27 10:06andrasNote Added: 0000744
2012-03-27 10:07andrasFile Added: omnetpp.patch
2012-03-27 10:07andrasFile Added: vector.patch
2012-03-27 10:07andrasNote Added: 0000745
2012-03-27 10:07andrasStatusnew => resolved
2012-03-27 10:07andrasFixed in Version => 4.2.2
2012-03-27 10:07andrasResolutionopen => fixed
2012-03-27 10:07andrasAssigned To => andras

Notes
(0000744)
andras   
2012-03-27 10:06   
From David Eckhoff:

I attached a patch for OMNeT++ 4.2 to modify some code and add a "memcheck" shell script to reproduce my output (cd samples/aloha; patch -p0 vector.patch; sh memcheck).

Executing the line in the memcheck file records statistics to valgrind.out. I attached an excerpt in valgrind.txt.

When uncommenting line 68 in Host.cc, that is doubling the number of recorded values, the amount of bytes 'totally lost' almost doubles, too.
I therefore conclude that its indeed the buffer.

Christoph and I dug a little deeper into the OMNeT++ code and we found something we think causes the memory leak:

cIndexedFileOutputVectorManager inherits from cFileOutputVectorManager and its sVector class inherits from the sVectorData class.

However, sVectorData has no virtual destructor.

The deregisterVector function (src/envir/fileoutvectormgr.cc:166) casts to sVectorData*, causing the destructor of sVector never to be called.
The buffer is therefore not deleted. I attached a patch (omnetpp.patch) that should fix the problem and close the memory leak.
(0000745)
andras   
2012-03-27 10:07   
Patch applied.