Bugzilla – Bug 1233
All tests and examples are getting Valgrind errors on darwin
Last modified: 2011-08-18 01:44:54 UTC
Currenty, all tests and examples are getting Valgrind errors on darwin. Here is the summary line from test.py: 0 of 167 tests passed (0 passed, 9 skipped, 0 failed, 0 crashed, 158 valgrind errors)
I tried version ns-3.11 on darwin. All tests and examples also get Valgrind errors using ns-3.11.
It appears that valgrind checks have always been disabled for darwin via the buildbots even prior to ns-3.10. Only in the past week has it been enabled. I am also trying to look at it when I get the opportunity (In reply to comment #1) > I tried version ns-3.11 on darwin. All tests and examples also get Valgrind > errors using ns-3.11.
Most , if not all valgrind errors are due to "still reachable" blocks. Per the valgrind website "still reachable" means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable. Don't use --show-reachable=yes if you don't want to see these reports. I have tried valgrind 3.6.1 , the valgrind port by "sealiesoftware", GLIBCXX/CPP_FORCE_NEW variable. But it does not help. Even the following simple code will report "still reachable". d-128-95-215-176:ns-3-dev nsnam$ cat test.cc #include <iostream> #include <vector> using namespace std; int main (int argc, char **argv) { vector <int> a ; a.push_back(1); return 0; } nsnam$ nsnam$ nsnam$ valgrind --error-exitcode=2 --dsymutil=yes ./test ==10973== Memcheck, a memory error detector ==10973== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==10973== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==10973== Command: ./test ==10973== ==10973== ==10973== HEAP SUMMARY: ==10973== in use at exit: 88 bytes in 1 blocks ==10973== total heap usage: 2 allocs, 1 frees, 92 bytes allocated ==10973== ==10973== LEAK SUMMARY: ==10973== definitely lost: 0 bytes in 0 blocks ==10973== indirectly lost: 0 bytes in 0 blocks ==10973== possibly lost: 0 bytes in 0 blocks ==10973== still reachable: 88 bytes in 1 blocks ==10973== suppressed: 0 bytes in 0 blocks ==10973== Rerun with --leak-check=full to see details of leaked memory ==10973== ==10973== For counts of detected and suppressed errors, rerun with: -v ==10973== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
All the valgrind errors are due to "still reachable" nsnam$ tail -1 a.out 0 of 167 tests passed (0 passed, 9 skipped, 0 failed, 0 crashed, 158 valgrind errors) nsnam$ grep "still reachable" a.out | grep -v "loss record" | uniq | wc -l 158 (In reply to comment #3) > Most , if not all valgrind errors are due to "still reachable" blocks. > > Per the valgrind website > "still reachable" means your program is probably ok -- it didn't free some > memory it could have. This is quite common and often reasonable. Don't use > --show-reachable=yes if you don't want to see these reports. > > I have tried valgrind 3.6.1 , the valgrind port by "sealiesoftware", > GLIBCXX/CPP_FORCE_NEW variable. But it does not help. > > > Even the following simple code will report "still reachable". > > > d-128-95-215-176:ns-3-dev nsnam$ cat test.cc > #include <iostream> > #include <vector> > > using namespace std; > > int main (int argc, char **argv) > { > vector <int> a ; > a.push_back(1); > return 0; > } > > nsnam$ > nsnam$ > nsnam$ valgrind --error-exitcode=2 --dsymutil=yes ./test > ==10973== Memcheck, a memory error detector > ==10973== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. > ==10973== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info > ==10973== Command: ./test > ==10973== > ==10973== > ==10973== HEAP SUMMARY: > ==10973== in use at exit: 88 bytes in 1 blocks > ==10973== total heap usage: 2 allocs, 1 frees, 92 bytes allocated > ==10973== > ==10973== LEAK SUMMARY: > ==10973== definitely lost: 0 bytes in 0 blocks > ==10973== indirectly lost: 0 bytes in 0 blocks > ==10973== possibly lost: 0 bytes in 0 blocks > ==10973== still reachable: 88 bytes in 1 blocks > ==10973== suppressed: 0 bytes in 0 blocks > ==10973== Rerun with --leak-check=full to see details of leaked memory > ==10973== > ==10973== For counts of detected and suppressed errors, rerun with: -v > ==10973== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
suggest to resolve as wontfix, due to it not being an ns-3 issue. I started a wiki section to track these kind of valgrind issues: http://www.nsnam.org/wiki/index.php/Troubleshooting#Valgrind_errors