|
From: Patrick O. <Pat...@in...> - 2004-08-06 10:05:45
|
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
|