|
From: Patrick O. <Pat...@in...> - 2004-08-06 08:37:32
Attachments:
syscalls.log.gz
|
Hi all,
I am trying to get valgrind 2.1.2 to run on Red Hat AS2.1
(libc 2.2.4, kernel 2.4.9-e.34smp) together with a program
which uses librt. I am aware of FAQ 3.4. For me it fails like this:
../hello: relocation error: /lib/i686/librt.so.1: symbol
__pthread_clock_settime, version GLIBC_2.2.3 not defined in file
libpthread.so.0 with link time
Therefore I patched vg_libpthread.vs like this:
GLIBC_2.2.3 {
# Extensions.
pthread_getattr_np;
+ __pthread_clock_gettime;
+ __pthread_clock_settime;
} GLIBC_2.2;
and then I got past that error, but I ran into another one:
valgrind --tool=none ../hello
==21264== Nulgrind, a binary JIT-compiler for x86-linux.
==21264== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas
Nethercote.
==21264== Using valgrind-2.1.2, a program supervision framework for
x86-linux.
==21264== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et
al.
==21264== For more details, rerun with: -v
==21264==
==21264== Warning: client syscall mmap2 tried to modify addresses
0xBFFF0000-0xC0000000
valgrind: vg_syscalls.c:3952 (after_mmap2): Assertion
`valid_client_addr((tst->m_eax), (tst->m_ecx), tid, "mmap2")' failed.
==21264== at 0xB002E510: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
==21264== by 0xB002E50F: assert_fail (vg_mylibc.c:1165)
==21264== by 0xB002E54D: vgPlain_core_assert_fail (vg_mylibc.c:1176)
==21264== by 0xB0044BC7: after_mmap2 (vg_syscalls.c:3952)
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==21264== at 0x3ABE751E: (within /lib/libredhat-kernel.so.1.0.1)
hello.c is really just the normal 'printf( "hello world\n" )'
example. It was compiled with:
"icc hello.c -o hello -lrt"
icc is the Intel compiler, Version 8.0 Build 20040716Z.
Attached is the output of the same run, but with --trace-syscalls=yes.
To get valgrind running I just removed the assert at vg_syscalls.c:3952
and then it works.
Now my question is: what is the right way to solve this?
Is the assert() really just invalid, or am I ignoring a more
fundamental problem by removing it?
On EL3.0 I have neither the librt nor the assert problem,
but "hello" also doesn't seem to use /dev/vsys as it does on
AS2.1.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a
50321 Bruehl
Germany
Tel: +49-2232-2090-30
Fax: +49-2232-2090-29
|
|
From: Tom H. <th...@cy...> - 2004-08-06 09:11:26
|
In message <1091781451.30388.108.camel@debian>
Patrick Ohly <Pat...@in...> wrote:
> ../hello: relocation error: /lib/i686/librt.so.1: symbol
> __pthread_clock_settime, version GLIBC_2.2.3 not defined in file
> libpthread.so.0 with link time
>
> Therefore I patched vg_libpthread.vs like this:
> GLIBC_2.2.3 {
> # Extensions.
> pthread_getattr_np;
> + __pthread_clock_gettime;
> + __pthread_clock_settime;
> } GLIBC_2.2;
> and then I got past that error, but I ran into another one:
That isn't actually the correct fix as it you're now assigning two
different versions to the symbol. In fact I'm surprised the linker
even allows that. I think I know what the correct fix is - could you
raise a bug for this please.
> ==21264== Warning: client syscall mmap2 tried to modify addresses
> 0xBFFF0000-0xC0000000
>
> valgrind: vg_syscalls.c:3952 (after_mmap2): Assertion
> `valid_client_addr((tst->m_eax), (tst->m_ecx), tid, "mmap2")' failed.
> ==21264== at 0xB002E510: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
> ==21264== by 0xB002E50F: assert_fail (vg_mylibc.c:1165)
> ==21264== by 0xB002E54D: vgPlain_core_assert_fail (vg_mylibc.c:1176)
> ==21264== by 0xB0044BC7: after_mmap2 (vg_syscalls.c:3952)
See bug 86289 for a discussion of this - it appears to be a bug in
the kernel you are using.
> To get valgrind running I just removed the assert at vg_syscalls.c:3952
> and then it works.
It does? I'm astonished.
> Now my question is: what is the right way to solve this?
> Is the assert() really just invalid, or am I ignoring a more
> fundamental problem by removing it?
No. The assert is absolutely valid. The only way it can fire as far
as I know is if the kernel process the mmap call wrongly.
If it does fire then it means the client has mapped some memory in
valgrind's reserved area of the address space and it won't then be
able to access that memory unless --pointercheck=no is used.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Patrick O. <Pat...@in...> - 2004-08-06 10:05:45
Attachments:
syscalls.assert.log.gz
syscalls.noassert.log.gz
|
On Fri, 2004-08-06 at 11:11, Tom Hughes wrote:
> In message <1091781451.30388.108.camel@debian>
> Patrick Ohly <Pat...@in...> wrote:
>
> > ../hello: relocation error: /lib/i686/librt.so.1: symbol
> > __pthread_clock_settime, version GLIBC_2.2.3 not defined in file
> > libpthread.so.0 with link time
> >
> > Therefore I patched vg_libpthread.vs like this:
> > GLIBC_2.2.3 {
> > # Extensions.
> > pthread_getattr_np;
> > + __pthread_clock_gettime;
> > + __pthread_clock_settime;
> > } GLIBC_2.2;
> > and then I got past that error, but I ran into another one:
>
> That isn't actually the correct fix as it you're now assigning two
> different versions to the symbol. In fact I'm surprised the linker
> even allows that. I think I know what the correct fix is - could you
> raise a bug for this please.
Okay, done (bug #86696).
>
> > ==21264== Warning: client syscall mmap2 tried to modify addresses
> > 0xBFFF0000-0xC0000000
> >
> > valgrind: vg_syscalls.c:3952 (after_mmap2): Assertion
> > `valid_client_addr((tst->m_eax), (tst->m_ecx), tid, "mmap2")' failed.
> > ==21264== at 0xB002E510: vgPlain_skin_assert_fail (vg_mylibc.c:1169)
> > ==21264== by 0xB002E50F: assert_fail (vg_mylibc.c:1165)
> > ==21264== by 0xB002E54D: vgPlain_core_assert_fail (vg_mylibc.c:1176)
> > ==21264== by 0xB0044BC7: after_mmap2 (vg_syscalls.c:3952)
>
> See bug 86289 for a discussion of this - it appears to be a bug in
> the kernel you are using.
Thanks for the pointer. In the future I'll not only search the mailing
list, but also the bug tracking system...
> > To get valgrind running I just removed the assert at vg_syscalls.c:3952
> > and then it works.
>
> It does? I'm astonished.
It ran "hello", "ls" (without false positives) but I haven't tested it
thoroughly with the app which uses librt yet. So you think it will fail
at some later stage while really checking errors?
BTW, after removing the assert() I also don't get the warning any more.
I just verified that once more. I ran "strace /tmp/valgrind/bin/valgrind
--tool=none /tmp/hello" with and without the assert (both attached)
and a diff shows that both runs do the offending mmap2 call,
but without the assert it continues like this:
mmap2(0x3a9a8000, 65536, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_FIXED, 6,
0) = 0xbfff0000
! fstat(6, {st_mode=S_IFCHR|0644, st_rdev=makedev(1, 10), ...}) = 0
! readlink("/proc/self/fd/6", "/dev/vsys", 4095) = 9
! close(6) = 0
! old_mmap(0x804d000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x804d000
while with the assert it aborts:
mmap2(0x3a9a8000, 65536, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_FIXED, 6,
0) = 0xbfff0000
! getpid() = 10167
! write(7798, "==10167== Warning: client syscal"..., 88==10167==
Warning: client syscall mmap2 tried to modify addresses
0xBFFF0000-0xC0000000
! ) = 88
! write(7798, "\nvalgrind: vg_syscalls.c:3952 (a"..., 90
! valgrind: vg_syscalls.c:3952 (after_mmap2): Assertion
`valid_client_addr((tst->m_eax), (t) = 90
! write(7798, "st->m_ecx), tid, \"mmap2\")\' faile"..., 35st->m_ecx),
tid, "mmap2")' failed.
Anyway, I guess I have to update the kernel because it also panics in
certain situations when running valgrind, f.i. when I abort a valgrind
run.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Software & Solutions Group
Hermuelheimer Strasse 8a
50321 Bruehl
Germany
Tel: +49-2232-2090-30
Fax: +49-2232-2090-29
|