Bug 1233

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