Bug 134 - TCP code leaks memory
TCP code leaks memory
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: internet
pre-release
All All
: P3 normal
Assigned To: ns-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-06 15:44 UTC by Rajib Bhattacharjea
Modified: 2008-07-01 13:32 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rajib Bhattacharjea 2008-02-06 15:44:45 UTC
Test case:
./waf --run=tcp-small-transfer --command-template="valgrind --tool=memcheck --leak-check=full --show-reachable=yes --db-attach=yes %s"

Some of the leaks seem to be related to sloppy management of new temporary PendingData buffers and calls to PendingData::CopyFromSeq.  One possible solution is to have this method return a Packet instead of a raw PendingData*.

Another leak seems to be related to the simulator and scheduling/canceling of the retransmission event (possibly related to bug 132?)
Comment 1 Rajib Bhattacharjea 2008-02-06 15:50:09 UTC
(In reply to comment #0)
the above should say bug 130, not bug 132.
Comment 2 Gustavo J. A. M. Carneiro 2008-02-10 07:11:37 UTC
(In reply to comment #0)
> Test case:
> ./waf --run=tcp-small-transfer --command-template="valgrind --tool=memcheck
> --leak-check=full --show-reachable=yes --db-attach=yes %s"
> 
> Some of the leaks seem to be related to sloppy management of new temporary
> PendingData buffers and calls to PendingData::CopyFromSeq.  One possible
> solution is to have this method return a Packet instead of a raw PendingData*.

You could also add reference counting methods to PendingData and then use Ptr<PendingData> instead of PendingData*.  Just to enumerate all the options, not saying this one is best...

> 
> Another leak seems to be related to the simulator and scheduling/canceling of
> the retransmission event (possibly related to bug 132?)
 
class Timer to the rescue! ;-)
Comment 3 Rajib Bhattacharjea 2008-02-25 17:22:26 UTC
TCP simulations now valgrind cleanly.  Fixed in 2353:5a1149f7de4e and 2354:ba9d1cad1a7c.

Summary:
When Simulator::Destroy is called, the call stack makes its way down to TcpSocket::Destroy.  If m_retxEvent.Cancel() is NOT called here (if its called in ~TcpSocket), then when ~TcpSocket is eventually hit, the simulator has already been destroyed, and the call to Simulator::Cancel actually CREATES a new SimulatorPrivate just before the program exits, causing the simulation to "leak".  The first change set fixes this issue. 

The second fixes some faulty memory management when pulling out copies of packets from TCPs outgoing TX buffer.