In the light of this and Julian's post, my practical experience may simply be a result of deadlocks that arise when the stdio library does its looking and my non-aware app does not include this into its looking scenario. Probably these deadlocks lead me to try valgrind to fix it, where the messages described here came up. Knowing that not always things are up to the spec, I concluded stdio is not thread safe. Obviously wrong. I still think it is better to avoid stdio in a heavily threaded app.
Rainer On Thu, Jan 29, 2009 at 11:06 AM, Bart Van Assche <bart.vanass...@gmail.com> wrote: > On Thu, Jan 29, 2009 at 9:58 AM, jody <jody....@gmail.com> wrote: >> I tried out DRD, but even though i read the DRD manual, >> i don't really understand the output (i used --tool=drd --var-info=yes -v) >> I get many messages concerning the same line, a print statement >> performed by the thread just before it exits the start func: >> ==19067== Conflicting store by thread 2/2 at 0x0400c018 size 4 >> ==19067== at 0x9E841C: mempcpy (in /lib/libc-2.7.so) >> ==19067== by 0x9B3814: vfprintf (in /lib/libc-2.7.so) >> ==19067== by 0x9BC9B2: printf (in /lib/libc-2.7.so) >> ==19067== by 0x8049745: OutputCollector::threadStart(void*) >> (OutputCollector.cpp:242) >> ==19067== by 0x400920A: vg_thread_wrapper (drd_pthread_intercepts.c:193) >> ==19067== by 0xB0950A: start_thread (in /lib/libpthread-2.7.so) >> ==19067== by 0xA4AB2D: clone (in /lib/libc-2.7.so) > > Can you please test either the Valgrind trunk or recompile the > Valgrind sources after having applied the patch you can find below ? > Instructions for downloading and building the Valgrind trunk can be > found here: http://www.valgrind.org/downloads/repository.html > > The above data race reported by DRD refers to internal variables of > the glibc library. The stdio implementation in glibc uses its own > locking implementation, and this implementation uses inline functions. > This makes it impossible for threading tools to intercept the locking > primitives used in the glibc stdio library. The patch below suppresses > data race reports where the top stack frame is in glibc. > > Modified: trunk/glibc-2.X-drd.supp > =================================================================== > --- trunk/glibc-2.X-drd.supp 2009-01-29 09:20:44 UTC (rev 9086) > +++ trunk/glibc-2.X-drd.supp 2009-01-29 09:57:22 UTC (rev 9087) > @@ -48,6 +48,11 @@ > fun:backtrace_symbols > } > { > + libc-stdio > + drd:ConflictingAccess > + obj:/lib*/libc-* > +} > +{ > libc > drd:ConflictingAccess > fun:__libc_enable_asynccancel > > Thanks, > > Bart. > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
