Bug 134

Summary:	TCP code leaks memory
Product:	ns-3	Reporter:	Rajib Bhattacharjea <raj.b>
Component:	internet	Assignee:	ns-bugs <ns-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	gjcarneiro
Priority:	P3
Version:	pre-release
Hardware:	All
OS:	All

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.