|
From: ERSEK L. <la...@ca...> - 2009-11-05 19:48:24
|
(Is SF broken? The web interface doesn't thread threads; whitespace formatting is lost even though my message was plain text; I didn't receive Julian's reply, even though I'm subscribed and receive commit logs and other messages; and only two thirds of the calendar table fit into a browser window 954 pixels wide.) On Thu, Nov 5, 2009 at 11:15 AM, Julian Seward <js...@ac...> wrote: > I believe Laszlo's comments are valid and correct, and an interesting > solution. I'd have to stare at it more it be convinced it's correct, but > it looks plausible. Thank you. I figured it might not be completely useless if somebody can compile her code with all these holding: - the code stays correct, - Valgrind headers are not installed -- no Valgrind specific ANNOTATE_* macros, - Valgrind still sees the condvar dependency in the binary in any case. (I think of this as a possible manual amendment, not a change to valgrind's instrumentation. I have no idea whether that would be possible at all.) > Laszlo, can you explain the background to this a bit? How did you come > to be looking at this problem? I develop lbzip2 (see <200...@ac...>), and the sponsor of my lbzip2 Debian package, Paul Wise, mentioned valgrind. I said I already tested with valgrind [0]. (Not because I was investigating a bug -- I was simply curious.) However, this made me remember reading some caveat in the Helgrind manual. I re-read that section and pthread_cond_timedwait() just occurred to me. > Does your solution help? I didn't try it out. If we cannot prove it's correct (or worse, we can disprove it), there's no need to. If we prove it correct, there's kinda no need to either :) Thanks, lacos [0] http://lists.debian.org/debian-mentors/2009/11/msg00060.html |
|
From: Bart V. A. <bar...@gm...> - 2009-11-05 20:13:39
|
On Thu, Nov 5, 2009 at 8:48 PM, ERSEK Laszlo <la...@ca...> wrote: > > Does your solution help? > > I didn't try it out. If we cannot prove it's correct (or worse, we can > disprove it), there's no need to. If we prove it correct, there's kinda no > need to either :) Hello Laszlo, Can you please post a small self-standing program or comment on Konstantin's test program (http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520) ? I prefer commenting on a program that can be compiled and run instead of commenting on incomplete program fragments. Bart. |
|
From: ERSEK L. <la...@ca...> - 2009-11-05 22:38:45
|
On Thu, 5 Nov 2009, Bart Van Assche wrote: > Can you please post a small self-standing program or comment on > Konstantin's test program > (http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520) > ? I prefer commenting on a program that can be compiled and run instead > of commenting on incomplete program fragments. Konstantin didn't get the false positives described in the manual. What I proposed is only for the case when there's a false positive to avert, so if there's no false positive then my proposition is automatically void. I installed valgrind-3.5.0 from source and wrote a small program: http://pastebin.com/f6a4181c2 (You'll have to hit enter after a second or so when running it.) I didn't get any false positives either. Cheers, lacos |
|
From: Konstantin S. <kon...@gm...> - 2009-11-06 07:09:23
|
I don't see any difference between this test and mine.
Pure happens-before detectors are silent, hybrid detectors report a (false)
race.
/usr/bin/gcc -Wall -Wextra -ansi -pedantic -o waittest -g3 waittest.c -l
pthread
% (sleep 1; echo) | ~/valgrind/trunk/inst/bin/valgrind --tool=drd -q
./waittest
1
% (sleep 1; echo) | ~/valgrind/trunk/inst/bin/valgrind --tool=helgrind -q
./waittest
1
% (sleep 1; echo) | tsan -q ./waittest
==22239== ThreadSanitizerValgrind: pure-happens-before=no fast-mode=yes
ignore-in-dtor=yes
1
% (sleep 1; echo) | tsan -q --fast-mode=no ./waittest
==22719== ThreadSanitizerValgrind: pure-happens-before=no fast-mode=no
ignore-in-dtor=yes
==22719== WARNING: Possible data race during read of size 4 at 0x601300: {{{
==22719== T0 (locks held: {}):
==22719== #0 main /tmp/waittest.c:79
==22719== Concurrent write(s) happened at (OR AFTER) these points:
==22719== T1 (locks held: {}):
==22719== #0 produce /tmp/waittest.c:17
==22719== #1 ThreadSanitizerStartThread ts_valgrind_intercepts.c:504
==22719== Address 0x601300 is 0 bytes inside data symbol
"msg_to_publish.2907"
==22719== }}}
==22719==
1
--kcc
On Fri, Nov 6, 2009 at 1:38 AM, ERSEK Laszlo <la...@ca...> wrote:
> On Thu, 5 Nov 2009, Bart Van Assche wrote:
>
> > Can you please post a small self-standing program or comment on
> > Konstantin's test program
> > (
> http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520
> )
> > ? I prefer commenting on a program that can be compiled and run instead
> > of commenting on incomplete program fragments.
>
> Konstantin didn't get the false positives described in the manual. What I
> proposed is only for the case when there's a false positive to avert, so
> if there's no false positive then my proposition is automatically void.
>
> I installed valgrind-3.5.0 from source and wrote a small program:
>
> http://pastebin.com/f6a4181c2
>
> (You'll have to hit enter after a second or so when running it.)
>
> I didn't get any false positives either.
>
> Cheers,
> lacos
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: ERSEK L. <la...@ca...> - 2009-11-06 11:14:39
|
On Fri, 6 Nov 2009, Konstantin Serebryany wrote: > I don't see any difference between this test and mine. I'm pleased to hear this, because then we're on the same page what should be tested and also because this means I didn't screw up too much. My purpose was not to create a different test case. I was just unfamiliar with the pthreads wrappers in your example. Further, I had the cursory impression that the same globals, mutexes and condvars were re-used for multiple tests and it made me uncomfortable to comment. I just wanted a bare-bones test case on the lowest pthreads level, because that's what all of us understand without any introduction. Thanks, lacos |
|
From: Bart V. A. <bar...@gm...> - 2009-11-06 07:27:04
|
On Thu, Nov 5, 2009 at 11:38 PM, ERSEK Laszlo <la...@ca...> wrote: > On Thu, 5 Nov 2009, Bart Van Assche wrote: > >> Can you please post a small self-standing program or comment on >> Konstantin's test program >> (http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520) >> ? I prefer commenting on a program that can be compiled and run instead >> of commenting on incomplete program fragments. > > Konstantin didn't get the false positives described in the manual. What I > proposed is only for the case when there's a false positive to avert, so > if there's no false positive then my proposition is automatically void. > > I installed valgrind-3.5.0 from source and wrote a small program: > > http://pastebin.com/f6a4181c2 Regarding the test program: the pointer-to-integer 'protected' is properly protected by locking, and the code that writes a value to *protected and the code that reads *protected is synchronized via the producer-consumer pattern. Helgrind and DRD will implicitly insert a happens-before arc between the producer and consumer, but ThreadSanitizer not. I believe that Konstantin proposed the ANNOTATE_PCQ_*() annotations some time ago in order to allow explicit annotation of the producer-consumer pattern in source code (see also http://article.gmane.org/gmane.comp.debugging.valgrind.devel/8398). P.S.: please use reply-all and don't modify the CC-list when replying. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2009-11-06 07:49:31
|
On Fri, Nov 6, 2009 at 10:26 AM, Bart Van Assche <bar...@gm...>wrote: > On Thu, Nov 5, 2009 at 11:38 PM, ERSEK Laszlo <la...@ca...> > wrote: > > On Thu, 5 Nov 2009, Bart Van Assche wrote: > > > >> Can you please post a small self-standing program or comment on > >> Konstantin's test program > >> ( > http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520 > ) > >> ? I prefer commenting on a program that can be compiled and run instead > >> of commenting on incomplete program fragments. > > > > Konstantin didn't get the false positives described in the manual. What I > > proposed is only for the case when there's a false positive to avert, so > > if there's no false positive then my proposition is automatically void. > > > > I installed valgrind-3.5.0 from source and wrote a small program: > > > > http://pastebin.com/f6a4181c2 > > Regarding the test program: the pointer-to-integer 'protected' is > properly protected by locking, and the code that writes a value to > *protected and the code that reads *protected is synchronized via the > producer-consumer pattern. Helgrind and DRD will implicitly insert a > happens-before arc between the producer and consumer, but > ThreadSanitizer not. ThreadSanitizer in the pure happens-before mode (--pure-happens-before=yes, NOT default) will behave exactly like Helgrind and DRD (see my previous reply). > I believe that Konstantin proposed the > ANNOTATE_PCQ_*() These will work, but there is a separate annotation specifically for cond var case. http://code.google.com/p/data-race-test/wiki/DynamicAnnotations#pthread_cond_wait_loop > annotations some time ago in order to allow explicit > annotation of the producer-consumer pattern in source code (see also > http://article.gmane.org/gmane.comp.debugging.valgrind.devel/8398). > > P.S.: please use reply-all and don't modify the CC-list when replying. > > Bart. > |