|
From: Jacob B. <ja...@do...> - 2004-10-11 18:43:00
|
Hi,
I'm having trouble with Valgrind 2.2.0 segfaulting immeadiatly before
any obvious processing has taken place, and I'd really like to get this
extremely useful utility working.
The crux of my problem is:
$ ./valgrind
Segmentation Fault
$
The build and install went smoothly using the following commands:
./configure --prefix=<somepath>
make clean all install
The output of gcc -v is:
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/specs
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix --disable-checking
--enable-long-long --enable-__cxa_atexit
--enable-languages=c,c++,ada,f77,objc,java
--host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)
As you can see, I am using a Mandrake 9.1 installation however the
installation has many modifications which are outside of my control
although these hopefuly shouldn't affect things like the libc or gcc
installation.
Uname tells me I am running Linux kernel version: 2.4.25-04dgr, although
this may also have been patched/modified outside of my control.
The output of 'strace ./valgrind' is:
execve("./valgrind", ["./valgrind"], [/* 84 vars */]) = 0
uname({sys="Linux", node="<blanked>", ...}) = 0
fcntl64(0, F_GETFD) = 0
fcntl64(1, F_GETFD) = 0
fcntl64(2, F_GETFD) = 0
geteuid32() = 566
getuid32() = 566
getegid32() = 1201
getgid32() = 1201
brk(0) = 0x80d9878
brk(0x80da878) = 0x80da878
brk(0x80db000) = 0x80db000
getrlimit(0x9, 0xba909604) = 0
setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
open("<somepath>/lib/valgrind/stage2", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=1706650, ...}) = 0
geteuid32() = 566
getegid32() = 1201
getgroups32(0x20, 0x80ce97c) = 5
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0L\276\0"..., 4096, 0) = 4096
pread(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0L\276\0"..., 52, 0) = 52
pread(3, "\6\0\0\0004\0\0\0004\0\0\2604\0\0\260\340\0\0\0\340\0\0"..., 224, 52) = 224
pread(3, "/lib/ld-linux.so.2\0", 19, 276) = 19
open("/lib/ld-linux.so.2", O_RDONLY|O_LARGEFILE) = 7
pread(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 52, 0) = 52
pread(7, "\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0I\27\1\0I\27\1\0\5\0\0"..., 96, 52) = 96
mmap2(0xb0000000, 544768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb0000000
mmap2(0xb0085000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x84) = 0xb0085000
mmap2(0xb0086000, 1417216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb0086000
mmap2(0xb1000000, 77300, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb1000000
mmap2(0xb1000000, 73728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0xb1000000
mmap2(0xb1012000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x11) = 0xb1012000
close(7) = 0
close(3) = 0
getpid() = 6690
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 +++
The output of ulimit -a is:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
Any hints on how to solve this problem would be great!
Thanks,
--
Jacob Bower <ja...@do...>
Department of Computing - http://www.doc.ic.ac.uk/
Imperial College - http://www.ic.ac.uk/
|
|
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
|