On Wed, Apr 14, 2010 at 8:34 AM, Rainer Gerhards <rgerha...@gmail.com>wrote:
> I am working with the svn version of valgrind (updated this morning).
> I see a series of violations in drd which I can not identify the root
> cause. An example violation looks like this:
>
> ==22593== Thread 3:
> ==22593== Conflicting load by thread 3 at 0x3401e1b328 size 4
> ==22593== at 0x3401C0E090: write (in /lib64/libpthread-2.11.1.so)
> ==22593== by 0x41D99A: dbgprint (debug.c:894)
> ==22593== by 0x41DB08: dbgprintf (debug.c:987)
> ==22593== by 0x4258B3: asyncWriterThread (stream.c:939)
> ==22593== by 0x4A12280: vgDrd_thread_wrapper
> (drd_pthread_intercepts.c:272)
> ==22593== by 0x3401C06A39: start_thread (in /lib64/libpthread-2.11.1.so
> )
> ==22593== Allocation context: BSS section of /lib64/libpthread-2.11.1.so
> ==22593== Other segment start (thread 1)
> ==22593== at 0x4A0993F: pthread_mutex_unlock
> (drd_pthread_intercepts.c:633)
> ==22593== by 0x427CEA: wtiSetState (wti.c:156)
> ==22593== by 0x427946: wtpAdviseMaxWorkers (wtp.c:519)
> ==22593== by 0x42C361: qqueueStart (queue.c:150)
> ==22593== by 0x40BA4A: init (syslogd.c:2400)
> ==22593== by 0x40C569: mainThread (syslogd.c:2856)
> ==22593== by 0x40DA16: realMain (syslogd.c:3554)
> ==22593== by 0x340101EB1C: (below main) (in /lib64/libc-2.11.1.so)
> ==22593== Other segment end (thread 1)
> ==22593== at 0x34010DE621: clone (in /lib64/libc-2.11.1.so)
> ==22593== by 0x3401C06333: do_clone.clone.0 (in /lib64/
> libpthread-2.11.1.so)
> ==22593== by 0x3401C07001: pthread_create@@GLIBC_2.2.5 (in
> /lib64/libpthread-2.11.1.so)
> ==22593== by 0x4A11DE8: pthread_cre...@* (drd_pthread_intercepts.c:409)
> ==22593== by 0x42795B: wtpAdviseMaxWorkers (wtp.c:520)
> ==22593== by 0x42C361: qqueueStart (queue.c:150)
> ==22593== by 0x40BA4A: init (syslogd.c:2400)
> ==22593== by 0x40C569: mainThread (syslogd.c:2856)
> ==22593== by 0x40DA16: realMain (syslogd.c:3554)
> ==22593== by 0x340101EB1C: (below main) (in /lib64/libc-2.11.1.so)
> ==22593==
>
> I can not identify which variable is at 0x3401e1b328. Given the alloc
> context, it looks like it is a static variable in the pthreads
> context. The code in question [1] does proper mutex locks before and
> after the relevant section. At least this is what I can identify. So I
> conclude that this is a "problem" in pthreads and I can safely create
> supressions for it. On the other hand, I do not understand why this
> only occurs in this instant, so I thought I better ask...
>
> Is this something that I can simply suppress or does it look like a
> real issue? If it is a real issue, can someone provide some advise on
> how to track it down?
>
Maybe it's the thread cancellation code that triggers the above race report.
Many system call wrappers in libpthread first check whether one or multiple
threads are active. If multiple threads are active, the cancellation type is
set to async before the system call and restored after the system call.
Bart.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
