Hi
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)
==19067== Allocation context: unknown.
==19067== Other segment start (thread 1/1)
==19067== at 0xA4AB18: clone (in /lib/libc-2.7.so)
==19067== by 0x40090C3: pthread_create* (drd_pthread_intercepts.c:295)
==19067== by 0x8049A4C: OutputCollector::start() (OutputCollector.cpp:103)
==19067== by 0x804918F: main (in /home/jody/progs/outputredir/OCTest)
==19067== Other segment end (thread 1/1)
==19067== at 0xB10748: accept (in /lib/libpthread-2.7.so)
==19067== by 0x804918F: main (in /home/jody/progs/outputredir/OCTest)
==19067== Other segment start (thread 1/1)
==19067== at 0xA4AB18: clone (in /lib/libc-2.7.so)
==19067== by 0x40090C3: pthread_create* (drd_pthread_intercepts.c:295)
==19067== by 0x8049A4C: OutputCollector::start() (OutputCollector.cpp:103)
==19067== by 0x804918F: main (in /home/jody/progs/outputredir/OCTest)
==19067== Other segment end (thread 1/1)
==19067== at 0xB10748: accept (in /lib/libpthread-2.7.so)
==19067== by 0x804918F: main (in /home/jody/progs/outputredir/OCTest)
I also get several messages concerning a print statement in the main thread
==19067== Conflicting load by thread 1/1 at 0x0400c000 size 11
==19067== at 0xA3B3EB: (within /lib/libc-2.7.so)
==19067== by 0x9DA134: new_do_write (in /lib/libc-2.7.so)
==19067== by 0x9DA41E: _IO_do_write@@GLIBC_2.1 (in /lib/libc-2.7.so)
==19067== by 0x9DAD27: _IO_file_overflow@@GLIBC_2.1 (in /lib/libc-2.7.so)
==19067== by 0x9DD792: __overflow (in /lib/libc-2.7.so)
==19067== by 0x9D170A: puts (in /lib/libc-2.7.so)
==19067== by 0x8049B42: OutputCollector::start() (OutputCollector.cpp:127)
==19067== by 0x804918F: main (in /home/jody/progs/outputredir/OCTest)
==19067== Allocation context: unknown.
==19067== Other segment start (thread 0/2)
==19067== (thread finished, call stack no longer available)
==19067== Other segment end (thread 0/2)
==19067== (thread finished, call stack no longer available)
==19067== Other segment start (thread 0/2)
==19067== (thread finished, call stack no longer available)
==19067== Other segment end (thread 0/2)
==19067== (thread finished, call stack no longer available)
In this particular case, only 1 thread was created which has exited long before
that statement has been reached.
I should add that the line 127 is
printf("Ended loop\n");fflush(stdout);
(i.e. no direct call of puts())
Could you help me interpret these results?
Thank You
Jody
On Wed, Jan 28, 2009 at 10:18 PM, Rainer Gerhards <rgerha...@gmail.com> wrote:
> I agree to these comments, but would also recommend to not *only* use
> helgrind but also the new DRD tool. DRD did an excellent job for my
> project. The newest release now contains a stable release.
>
> Just my 2cts...
>
> Rainer
>
> On Wed, Jan 28, 2009 at 6:44 PM, Julian Seward <jsew...@acm.org> wrote:
>>
>>> I have a server which creates a new detached pthread every time it
>>> accepts a new connection.
>>
>> Hmm, detached threads are bad news, at least from a race detection
>> point of view. See
>>
>> http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use
>> point 5 ("Round up all finished threads using pthread_join. ...").
>>
>> Try to pthread_join all your threads before the end of the program
>> and see if that improves the situation. Maybe the lock you added
>> isn't really necessary.
>>
>>> My question is: has there really been a data race, or did valgrind
>>> only decide that if the timing is right, there could be a data race?
>>>
>>> >From the way i see it, there could not have been a real data race...
>>
>> But because your threads are detached, Helgrind cannot know when they
>> finish (logically) relative to each other and the parent. That's why
>> it is better to pthread_join to them.
>>
>> J
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
