|
From: Julian S. <js...@ac...> - 2011-10-27 07:11:02
|
On Thursday, October 27, 2011, Florian Krohm wrote: > helgrind/tests/cond_timedwait_invalid is failing on x86-linux. > There is an additional line in the backtrace. Unfiltered, the > backtrace looks like this: > > ==28111== Thread #1's call to pthread_cond_timedwait failed > ==28111== with error code 22 (EINVAL: Invalid argument) > ==28111== at 0x4029F3B: pthread_cond_timedwait_WRK (hg_intercepts.c:784) > ==28111== by 0x4029F7F: pthread_cond_timedwait@* (hg_intercepts.c:797) > ==28111== by 0x4125DF3: pthread_cond_timedwait@@GLIBC_2.3.2 > (forward.c:152) > ==28111== by 0x80485DF: main (cond_timedwait_invalid.c:22) > > Note the line referring to pthread_cond_timedwait@@GLIBC_2.3.2 > which should not be there because pthread_cond_timedwait is > supposed to be intercepted and wrapped. My guess what's happening is: main calls pthread_cond_timedwait, which winds up in the libc.so version. That has page offset 0xdb0, and the call out from it has a return point with page offset 0xDF3, just a bit along from the start, so that seems plausible. This function in turn calls the pthread_cond_timedwait in libpthread, which is intercepted as required by the intercept machinery. The intercept specifications are (soname, functionname) pairs, so there is no possibility that the intercept machinery would accidently intercept pthread_cond_timedwait@* in libc.so instead of the version in libpthread.so. And indeed .. > (1) /usr/lib/debug/lib/libc-2.12.1.so > $ nm /usr/lib/debug/lib/libc-2.12.1.so | grep pthread_cond_timedwait > 000dddb0 T pthread_cond_timedwait@@GLIBC_2.3.2 > 0010fa50 T pthread_cond_timedwait@GLIBC_2.0 > > (2) /usr/lib/debug/lib/libpthread-2.12.1.so > $ nm /usr/lib/debug/lib/libpthread-2.12.1.so | grep > pthread_cond_timedwait > 0000a730 T pthread_cond_timedwait@@GLIBC_2.3.2 > 0000ae50 T pthread_cond_timedwait@GLIBC_2.0 > ==28287== Adding active redirection: > --28287-- new: 0x041af730 (pthread_cond_timedwait@@GLIBC_2.3.2) W-> > (0000.0) 0x04029f69 pthread_cond_timedwait@* > > --28287-- REDIR: 0x41af730 (pthread_cond_timedwait@@GLIBC_2.3.2) > redirected to 0x4029f69 (pthread_cond_timedwait@*) These both intercept a function with page offset 0x730, which is can only be pthread_cond_timedwait@@GLIBC_2.3.2 in libpthread-2.12.1.so. So I don't think there's a redir bug. Now, why it's linked against librt instead of libpthread, I have no idea. Can you get any useful info from svn ann and then svn log of the relevant Makefile.am? All else being equal, it sounds to me cleaner to link against libpthread, but perhaps there was some special reason to link against librt. J |