> I already went over the manual, and did not find anything that helped > including the --freelist-* flags.
Please read more carefully. I found relevant material which I pinpoint below in the hope that specific references may help increase understanding for future uses. I downloaded the manual from http://www.valgrind.org/docs/download_docs.html pointing to http://www.valgrind.org/docs/manual/valgrind_manual.pdf (1301228 bytes) titled Valgrind Documentation, Release 3.8.0 10 August 2012 . Then I read: In the chapter Memcheck: a memory error detector, section 4.3. Memcheck Command-Line Options, printed p.58, pdf p.70 of 319: --freelist-vol=<number> [default: 20000000] and on printed p.59, pdf p.71 of 319: --freelist-big-blocks=<number> [default: 1000000] Hints to these command line options also appear in the output from "valgrind --help". > I found answers for all of your questions below, but they are not relevant > any more. Well, actually some of them still provide important educational clues. Using the standalone test case that you posted, and comparing static linking versus dynamic on x86_64: VIRT RES SHR /usr/bin/top 1012 16 8 ./my_test static linking libc.a 4112 312 240 ./my_test dynamic linking libc.so.6 If the SHR column shows only 8KiB, then that is a very strong clue that the program is not using a shared libc. As you discovered, this turns out to be the reason for the problems that you encountered. > > Following your advice to construct the smallest stand-alone test case, > I saw that the problem persists if tested at the start of main() when using > the same build system. > After a lot of further testing I found the reason: > The executable that valgrind examines is statically linked. > It looks like valgrind must work with a shared glibc to recognize calls to > malloc/free. > BTW The identification of uninitialized memory also does not work properly > with the statically linked executable. > > I do not see this information in the manual, perhaps it is worth adding to > the "Getting Started" section. In the Valgrind Frequently Asked Questions, section 4. Valgrind behaves unexpectedly, 4.5. Memcheck doesn’t report any errors and I know my program has errors, printed p.6, pdf p.183 of 319: Second, if your program is statically linked, most Valgrind tools won’t work as well, because they won’t be able to replace certain functions, such as malloc, with their own versions. In the NEWS section, Release 3.8.0 (10 August 2012), TOOL CHANGES, * Non-libc malloc implementations are now supported. This is useful for tools that replace malloc (Memcheck, Massif, DRD, Helgrind). Using the new option --soname-synonyms, such tools can be informed that the malloc implementation is either linked statically into the executable, or is present in some other shared library different from libc.so. This makes it possible to process statically linked programs, and programs using other malloc libraries, for example TCMalloc or JEMalloc. So valgrind-3.8.0 says that it can handle static linking of malloc, but the user must help. > > In case you still want a full test case, here it is, to be compiled with: gcc > -m32 -g -static test.c Thank you for posting the code; I snipped it from this reply. "Construct the smallest bad example" is an amazingly helpful approach. I'm glad that you succeeded in finding the problem. -- ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
