> I am trying to find memory corruption using valgrind/memcheck. > I am running a big executable, and noticed that memory access outside > allocated areas is not detected. This happens after very many memory > allocations are performed.
How big (numbers, please)? Run /usr/bin/top and report the VIRT RES SHR amounts for the process, both without and with valgrind/memcheck. How many allocations and how many calls to free()? What is the distribution of block sizes? What is the distribution of calls to malloc, realloc, memalign, mmap? > I am testing access to illegal memory and finding that access to memory > beyond the boundaries of memory just allocated by malloc is not reported. > Access to memory after it is freed by free() is not reported. > Access to memory which is not mapped in virtual memory is reported. > > This is not due to too many errors, and I suspect that the valgrind data > structures holding allocations and de-allocations get full, and therefore > stop functioning. This is just a guess, I have no information about the > mechanism. I do know that the executable uses a big amount of memory > allocations. There is no limit to the tracking of blocks which have been allocated but not yet free()d. There are some limits on tracking accesses to blocks which have been free()d. The address space is tracked as free, but the identity of the most recent block that was associated with that space is forgotten. First, large blocks (--freelist-big-blocks=<number>) lose their identity immediately upon free(). Second, there is a queue (--freelist-vol=<number>) of free()d small blocks, and old blocks are forgotten as new ones are free()d. > > Is there a way to check print the memory allocations and de-allocations that > valgrind is tracking at a specific point? Read The Fine Manual. If you don't know where it is, then search for "valgrind manual". > Is there a limit to the number of allocations that can be handled? There is no limit other than total address space available to the process. > > I am running on Linux x86_64. > I tried using both valgrind-3.8.1 and valgrind-3.5.0 that comes with the open > Suse 11.3 I am running on. > I tried this with both a 32 bit and a 64 bit executable. > Example command line that I use: valgrind --trace-children=yes > --error-limit=no -v ./executable Thank you for those details! You care enough that there is hope for this case. > > Does anyone have an idea what to do here? Construct the smallest stand-alone test case which illustrates the problem(s), and post that code. If you actually do wade into this then you will find that valgrind/memcheck really does work even for "big programs", and that there is something unusual about your program or environment that triggers the problems. -- ------------------------------------------------------------------------------ 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
