HOWTO use Valgrind to debug memory problems
Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects
Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers
Memory leaks or errors can be found with Valgrind. Support for valgrind is built into the ./waf system by typing:
./waf --command-template="valgrind [options] %s" --run ns-3-program-name
for example:
./waf --command-template="valgrind --leak-check=full --show-reachable=yes %s" -- run main-propagation-loss
Common errors
Please list hints here as to what kind of errors have known resolution.
Failure to call Simulator::Destroy()
Simulator::Destroy() will free memory that is created with the ns-3 object system. Forgetting to call Simulator::Destroy () when you are done will lead to reachable memory being reported by valgrind, such as this trace of the main-propagation-loss example:
==16325== 88 bytes in 1 blocks are still reachable in loss record 4 of 4 ==16325== at 0x4A069D5: operator new(unsigned long) (vg_replace_malloc.c:261) ==16325== by 0x4C87A6B: ns3::TypeId ns3::TypeId::AddConstructor<ns3::DefaultSimulatorImpl>()::Maker::Create() (type-id.h:429) ==16325== by 0x4C778A3: ns3::FunctorCallbackImpl<ns3::ObjectBase* (*)(), ns3::ObjectBase*, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::operator()() (callback.h:166) ==16325== by 0x4CBF22C: ns3::Callback<ns3::ObjectBase*, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty>::operator()() const (callback.h:407) ==16325== by 0x4CBE05E: ns3::ObjectFactory::Create() const (object-factory.cc:69) ==16325== by 0x4C8569E: ns3::Ptr<ns3::SimulatorImpl> ns3::ObjectFactory::Create<ns3::SimulatorImpl>() const (object-factory.h:110) ==16325== by 0x4C823FB: ns3::GetImpl() (simulator.cc:93) ==16325== by 0x4C831B1: ns3::Simulator::Stop(ns3::Time const&) (simulator.cc:184) ==16325== by 0x404157: TestDeterministic(ns3::Ptr<ns3::PropagationLossModel>) (main-propagation-loss.cc:83) ==16325== by 0x405CC1: main (main-propagation-loss.cc:225) ==16325== ==16325== LEAK SUMMARY: ==16325== definitely lost: 0 bytes in 0 blocks ==16325== indirectly lost: 0 bytes in 0 blocks ==16325== possibly lost: 0 bytes in 0 blocks ==16325== still reachable: 200 bytes in 4 blocks ==16325== suppressed: 0 bytes in 0 blocks ==16325== ==16325== For counts of detected and suppressed errors, rerun with: -v ==16325== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
Here, the clue is the line that says "ns3::Ptr<ns3::SimulatorImpl> ns3::ObjectFactory::Create<ns3::SimulatorImpl>() const (object-factory.h:110)" and the lines above it. If you see an error such as that reporting "still reachable" blocks, it is often the case that you forgot to call Simulator::Destroy() to free objects that have been created as factory objects.
