(In reply to comment #0)
the above should say bug 130, not bug 132.

(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! ;-)

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.