|
Bugzilla – Full Text Bug Listing |
| Summary: | Memory leak in TestSuite routing-aodv-regression | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Craig Dowell <craigdo> |
| Component: | routing | Assignee: | ns-bugs <ns-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | andreev, faker.moatamri, mathieu.lacage |
| Priority: | P1 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
commented ping
Proposed fix Clear the list of sockets in ipv4-l3-protocol.cc |
||
|
Description
Craig Dowell
2010-01-12 18:38:27 UTC
Actually this is not only for routing aodv regression: utils/test-runner --suite=routing-aodv-regression still reachable: 936 bytes in 7 blocks utils/test-runner --suite=routing-aodv still reachable: 280 bytes in 6 blocks utils/test-runner --suite=routing-olsr-regression still reachable: 200 bytes in 4 blocks utils/test-runner --suite=routing-olsr-header definitely lost: 224 bytes in 2 blocks. indirectly lost: 17,256 bytes in 150 blocks. possibly lost: 0 bytes in 0 blocks. still reachable: 200 bytes in 4 blocks. utils/test-runner --suite=ipv6-protocol still reachable: 200 bytes in 4 blocks utils/test-runner --suite=packetbb-test-suite still reachable: 5,816 bytes in 42 blocks utils/test-runner --suite=drop-tail-queue still reachable: 720 bytes in 16 blocks utils/test-runner --suite=packet-metadata still reachable: 936 bytes in 7 blocks utils/test-runner --suite=buffer 200 bytes in 4 blocks utils/test-runner --suite=object-name-service still reachable: 200 bytes in 4 blocks examples/stats/wifi-example-sim still reachable: 200 bytes in 4 blocks examples/tcp/star still reachable: 200 bytes in 4 blocks and there is some others like those plus valgrind is returning 0 which doesn't allow us to detect the errors. I think this is more than just an error in a test program. Any thoughts? > examples/tcp/star > still reachable: 200 bytes in 4 blocks > > and there is some others like those plus valgrind is returning 0 > which doesn't allow us to detect the errors. I think this is more > than just an error in a test program. Any thoughts? This is expected behavior. It has been like this since ns-3.1 and is due to the fact that valgrind doesn't consider still-reachable an "important" error since "such blocks don't need direct fixing by the programmer." Created attachment 723 [details]
commented ping
If I comment installing ping, valgrind is happy
Created attachment 724 [details]
Proposed fix
Just stop the ping a nanosecond before end regression test ends
(In reply to comment #4) > Created an attachment (id=724) [details] > Proposed fix > > Just stop the ping a nanosecond before end regression test ends Woow. Why is this fixing the leak ??? Is it because the Socket::Close function is doing something special ? If so, what ? StopApplication is already not called, and RawSocket is not closed You schedule stopevent for application like this: m_stopEvent = Simulator::Schedule (m_stopTime, &Application::StopApplication, this); and Simulator may be already destroyed Created attachment 725 [details]
Clear the list of sockets in ipv4-l3-protocol.cc
This fix will clear the memory leak, actually in ipv4-l3-protocol.cc, the DoDispose function doesn't clear the list of sockets it has, that's what is causing the memory leak. Here is a patch that fixes it.
I verified that clearing m_sockets cleans up the following errors: ==7504== definitely lost: 224 bytes in 2 blocks ==7504== indirectly lost: 17,256 bytes in 150 blocks Another error remains after this patch is applied: ==7504== still reachable: 200 bytes in 4 blocks I have filed a separate bug on these, so it seems to me that applying the patch above should close this particular bug. I'm a little troubled that something as blatant as this would not appear somewhere else, though; so maybe this is all related. Changeset: 8f94a0ca3964 |