|
From: Nicholas N. <nj...@ca...> - 2004-10-12 08:52:50
|
On Mon, 11 Oct 2004, Jacob Bower wrote:
> The output of 'strace ./valgrind' is:
>
> execve("./valgrind", ["./valgrind"], [/* 84 vars */]) = 0
> [...]
> open("/tmp/.pad.6690.1", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0) = 3
> unlink("/tmp/.pad.6690.1") = 0
> open("/proc/self/maps", O_RDONLY|O_LARGEFILE) = 7
> read(7, "00000000-00000000 r-xp 00000000 "..., 10240) = 593
> close(7) = 0
> mmap2(NULL, 2969567232, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
That final mmap2() call is asking for 2.9GB of memory to be mapped,
starting at address 0x0. That's clearly bogus, and is almost certainly
trashing lots of real memory. So the question is, why is Valgrind doing
this?
The read() call is interesting -- looks like the first line in
/proc/self/maps is
0000000-00000000 r-xp 00000000 ...
What does that mean? I wonder if this zero-sized segment is confusing
Valgrind, eg. causing some arithmetic overflow because it doesn't expect
zero-size segments. Can you show us the output of 'cat /proc/self/maps'?
To go further yourself, you could try inserting diagnostic fprintf() calls
in order to determine exactly which mmap2() call is failing -- I think the
problem is in coregrind/ume.c, in particular the function as_pad() or
foreach_map(). If you find the location, if you could also determine the
particular problem by looking judiciously at some variable values (eg. is
it an arithmetic overflow problem?) that would be a great help. Sorry to
have to ask you to do this but it's difficult to debug this ourselves.
N
|