Hello John.
I already went over the manual, and did not find anything that helped including
the --freelist-* flags.
I found answers for all of your questions below, but they are not relevant any
more.
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 case you still want a full test case, here it is, to be compiled with: gcc
-m32 -g -static test.c
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char *argv[])
{
unsigned int *p;
printf("======================================================= malloc\n");
if ((p = malloc(24))) {
int i;
for (i=0; i<=5; ++i) {
p[i]=i;
}
p[0]=p[6]+p[7]+p[8];
p[1]=p[-1]+p[-2]+p[-3];
printf("=======================================================
free\n");
free(p);
p[1] = p[0];
}
return 0;
}
Thanks for the help,
Gili
> > 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
