Hi all, 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? Thanks, Rainer [1] http://git.adiscon.com/?p=rsyslog.git;a=blob;f=runtime/debug.c;h=da471609f01c6e11dd3274819b6d8f48bc0695de;hb=refs/heads/v4-devel#l842 ------------------------------------------------------------------------------ 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
