You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(12) |
2
(9) |
|
3
(23) |
4
(24) |
5
(9) |
6
(7) |
7
(5) |
8
(2) |
9
(6) |
|
10
(5) |
11
(3) |
12
(11) |
13
(4) |
14
|
15
(3) |
16
(4) |
|
17
(3) |
18
(6) |
19
|
20
(1) |
21
(9) |
22
(8) |
23
(1) |
|
24
|
25
(2) |
26
(3) |
27
(16) |
28
(17) |
29
(22) |
30
(7) |
|
31
(4) |
|
|
|
|
|
|
|
From: <sv...@va...> - 2010-01-29 22:37:14
|
Author: sewardj
Date: 2010-01-29 22:37:02 +0000 (Fri, 29 Jan 2010)
New Revision: 11033
Log:
PE/PDB handling: allow the PDB (the debuginfo file) to be up to 1
minute older than the PE (the .exe/.dll it describes) even though this
doesn't seem particularly safe. Partially fixes #190675.
(patch from Dan Kegel)
Modified:
trunk/coregrind/m_debuginfo/debuginfo.c
Modified: trunk/coregrind/m_debuginfo/debuginfo.c
===================================================================
--- trunk/coregrind/m_debuginfo/debuginfo.c 2010-01-28 15:23:54 UTC (rev 11032)
+++ trunk/coregrind/m_debuginfo/debuginfo.c 2010-01-29 22:37:02 UTC (rev 11033)
@@ -971,9 +971,15 @@
goto out;
}
pdb_mtime = stat_buf.mtime;
- if (pdb_mtime < obj_mtime ) {
- /* PDB file is older than PE file - ignore it or we will either
- (a) print wrong stack traces or more likely (b) crash. */
+
+ if (obj_mtime - pdb_mtime > 60ULL) {
+ /* PDB file is older than PE file. Really, the PDB should be
+ newer than the PE, but that doesn't always seem to be the
+ case. Allow the PDB to be up to one minute older.
+ Otherwise, it's probably out of date, in which case ignore it
+ or we will either (a) print wrong stack traces or more likely
+ (b) crash.
+ */
VG_(message)(Vg_UserMsg,
"Warning: Ignoring %s since it is older than %s\n",
pdbname, exename);
|
|
From: Greg P. <gp...@ap...> - 2010-01-29 21:34:57
|
On Jan 29, 2010, at 2:56 AM, Bart Van Assche wrote: > On Fri, Jan 29, 2010 at 11:48 AM, Konstantin Serebryany > <kon...@gm...> wrote: >> >> hm. maybe. dunno. >> Usually, such checking is hacked into the implementation of the >> synchronization utlility itself... No? > > The POSIX spec is ambiguous about reinitialization. Two quotes from > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_barrier_init.html: > * The results are undefined if pthread_barrier_init() is called > specifying an already initialized barrier. > * [EBUSY] The implementation has detected an attempt to reinitialize a > barrier while it is in use (for example, while being used in a > pthread_barrier_wait() call) by another thread. > > Or: while it is specified that reinitializing an already initialized > barrier yields undefined results, it is not specified that > pthread_barrier_init() must return an error code when reinitializing a > barrier that is not in use. It is also not specified that pthread_barrier_init() must return an error code when reinitializing a barrier that is in use. Note that EBUSY is "may fail", not "shall fail". That means the implementation is allowed to return that error, but the implementation is also allowed to omit that safety check completely. The behavior of reinitialization is undefined. The meaning of EBUSY is defined, but the implementation is free to do something else instead. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Bart V. A. <bva...@ac...> - 2010-01-29 15:49:16
|
On Fri, Jan 29, 2010 at 12:09 PM, Julian Seward <js...@ac...> wrote: > > > * Some barrier implementations (e.g. the one in libgomp) allow barrier > > reinitialization while others (e.g. POSIX threads) do not allow this. > > If we want threading tools to be able to complain about barrier > > reinitialization for barrier types for which this is not allowed we > > need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool > > whether or not reinitialization is allowed. > > Yes, +1 for that. > > Can you also do the other changes we discussed, so that the different > annotation sets can stay in sync? > > * get rid of ANNOTATE_UNPUBLISH and ANNOTATE_PUBLISH > > * rename ANNOTATE_HAPPENS_BEFORE(obj) > to ANNOTATE_HAPPENS_BEFORE_ACCUMULATE(obj) > maybe add a #define for backwards compatibility > > * add ANNOTATE_HAPPENS_BEFORE_OVERWRITE(obj) > > * add ANNOTATE_HAPPENS_BEFORE_FORGET(obj) > Hello Julian, Is the above question intended for me or for Konstantin ? Bart. |
|
From: Konstantin S. <kon...@gm...> - 2010-01-29 11:24:09
|
PTAL (==please take a[nother] look) http://codereview.appspot.com/196059/patch/11/1005 On Fri, Jan 29, 2010 at 2:12 PM, Bart Van Assche <bva...@ac...> wrote: > On Fri, Jan 29, 2010 at 12:06 PM, Konstantin Serebryany > <kon...@gm...> wrote: > > > > > > On Fri, Jan 29, 2010 at 2:09 PM, Julian Seward <js...@ac...> wrote: > >> > >> > * Some barrier implementations (e.g. the one in libgomp) allow barrier > >> > reinitialization while others (e.g. POSIX threads) do not allow this. > >> > If we want threading tools to be able to complain about barrier > >> > reinitialization for barrier types for which this is not allowed we > >> > need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool > >> > whether or not reinitialization is allowed. > >> > >> Yes, +1 for that. > > > > So, what would be the code like? > > /* Report that the "barrier" has been initialized with initial "count". > > If allow_reinitialization is true, barrier_init() is allowed to be > called > > multiple times > > w/o calling barrier_destroy() */ > > #define ANNOTATE_BARRIER_INIT(barrier, count, allow_reinitialization) > > ? > > Maybe "reinitialization_allowed" instead of "allow_reinitialization" ? > > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2010-01-29 11:12:40
|
On Fri, Jan 29, 2010 at 12:06 PM, Konstantin Serebryany <kon...@gm...> wrote: > > > On Fri, Jan 29, 2010 at 2:09 PM, Julian Seward <js...@ac...> wrote: >> >> > * Some barrier implementations (e.g. the one in libgomp) allow barrier >> > reinitialization while others (e.g. POSIX threads) do not allow this. >> > If we want threading tools to be able to complain about barrier >> > reinitialization for barrier types for which this is not allowed we >> > need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool >> > whether or not reinitialization is allowed. >> >> Yes, +1 for that. > > So, what would be the code like? > /* Report that the "barrier" has been initialized with initial "count". > If allow_reinitialization is true, barrier_init() is allowed to be called > multiple times > w/o calling barrier_destroy() */ > #define ANNOTATE_BARRIER_INIT(barrier, count, allow_reinitialization) > ? Maybe "reinitialization_allowed" instead of "allow_reinitialization" ? Bart. |
|
From: Konstantin S. <kon...@gm...> - 2010-01-29 11:07:11
|
On Fri, Jan 29, 2010 at 2:09 PM, Julian Seward <js...@ac...> wrote: > > > * Some barrier implementations (e.g. the one in libgomp) allow barrier > > reinitialization while others (e.g. POSIX threads) do not allow this. > > If we want threading tools to be able to complain about barrier > > reinitialization for barrier types for which this is not allowed we > > need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool > > whether or not reinitialization is allowed. > > Yes, +1 for that. > So, what would be the code like? /* Report that the "barrier" has been initialized with initial "count". If allow_reinitialization is true, barrier_init() is allowed to be called multiple times w/o calling barrier_destroy() */ #define ANNOTATE_BARRIER_INIT(barrier, count, allow_reinitialization) ? > > Can you also do the other changes we discussed, so that the different > annotation sets can stay in sync? > > * get rid of ANNOTATE_UNPUBLISH and ANNOTATE_PUBLISH > I can't just remove them, there are used in several places. I already marked them as DEPRECATED. > > * rename ANNOTATE_HAPPENS_BEFORE(obj) > to ANNOTATE_HAPPENS_BEFORE_ACCUMULATE(obj) > maybe add a #define for backwards compatibility > > * add ANNOTATE_HAPPENS_BEFORE_OVERWRITE(obj) > > * add ANNOTATE_HAPPENS_BEFORE_FORGET(obj) > I will, as a separate change. > > J > |
|
From: Julian S. <js...@ac...> - 2010-01-29 10:58:46
|
On Friday 29 January 2010, Konstantin Serebryany wrote: > On Fri, Jan 29, 2010 at 1:39 PM, Bart Van Assche <bva...@ac...> wrote: > > On Fri, Jan 29, 2010 at 11:33 AM, Konstantin Serebryany > > > > <kon...@gm...> wrote: > > > Please check here: http://codereview.appspot.com/196059/patch/1/3 > > > > Looks good to me. The only remarks I have are: > > * A nit pick: personally I would call the second argument of > > ANNOTATE_BARRIER_INIT() "count" instead of "counter". > > fixed > > > * Some barrier implementations (e.g. the one in libgomp) allow barrier > > reinitialization while others (e.g. POSIX threads) do not allow this. > > If we want threading tools to be able to complain about barrier > > reinitialization for barrier types for which this is not allowed we > > need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool > > whether or not reinitialization is allowed. > > hm. maybe. dunno. > Usually, such checking is hacked into the implementation of the > synchronization utlility itself... No? Better to keep implementation and specification separate. Since the may/may-not-be-reinitialised property is something a tool might want to check, we need a way to tell it whether the barrier may be reinitialised. J |
|
From: Bart V. A. <bva...@ac...> - 2010-01-29 10:57:02
|
On Fri, Jan 29, 2010 at 11:48 AM, Konstantin Serebryany <kon...@gm...> wrote: > > On Fri, Jan 29, 2010 at 1:39 PM, Bart Van Assche <bva...@ac...> wrote: >> >> On Fri, Jan 29, 2010 at 11:33 AM, Konstantin Serebryany >> <kon...@gm...> wrote: >> > Please check here: http://codereview.appspot.com/196059/patch/1/3 >> >> Looks good to me. The only remarks I have are: >> * A nit pick: personally I would call the second argument of >> ANNOTATE_BARRIER_INIT() "count" instead of "counter". > > fixed Thanks. >> * Some barrier implementations (e.g. the one in libgomp) allow barrier >> reinitialization while others (e.g. POSIX threads) do not allow this. >> If we want threading tools to be able to complain about barrier >> reinitialization for barrier types for which this is not allowed we >> need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool >> whether or not reinitialization is allowed. > > hm. maybe. dunno. > Usually, such checking is hacked into the implementation of the > synchronization utlility itself... No? The POSIX spec is ambiguous about reinitialization. Two quotes from http://www.opengroup.org/onlinepubs/000095399/functions/pthread_barrier_init.html: * The results are undefined if pthread_barrier_init() is called specifying an already initialized barrier. * [EBUSY] The implementation has detected an attempt to reinitialize a barrier while it is in use (for example, while being used in a pthread_barrier_wait() call) by another thread. Or: while it is specified that reinitializing an already initialized barrier yields undefined results, it is not specified that pthread_barrier_init() must return an error code when reinitializing a barrier that is not in use. So the only sure way to catch this kind of POSIX violations is to let the thread checking tool verify this. And a tool can only verify this when it has been informed about whether or not barrier reinitialization is allowed. Bart. |
|
From: Julian S. <js...@ac...> - 2010-01-29 10:55:48
|
> * Some barrier implementations (e.g. the one in libgomp) allow barrier > reinitialization while others (e.g. POSIX threads) do not allow this. > If we want threading tools to be able to complain about barrier > reinitialization for barrier types for which this is not allowed we > need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool > whether or not reinitialization is allowed. Yes, +1 for that. Can you also do the other changes we discussed, so that the different annotation sets can stay in sync? * get rid of ANNOTATE_UNPUBLISH and ANNOTATE_PUBLISH * rename ANNOTATE_HAPPENS_BEFORE(obj) to ANNOTATE_HAPPENS_BEFORE_ACCUMULATE(obj) maybe add a #define for backwards compatibility * add ANNOTATE_HAPPENS_BEFORE_OVERWRITE(obj) * add ANNOTATE_HAPPENS_BEFORE_FORGET(obj) J |
|
From: Konstantin S. <kon...@gm...> - 2010-01-29 10:49:23
|
On Fri, Jan 29, 2010 at 1:39 PM, Bart Van Assche <bva...@ac...> wrote: > On Fri, Jan 29, 2010 at 11:33 AM, Konstantin Serebryany > <kon...@gm...> wrote: > > Please check here: http://codereview.appspot.com/196059/patch/1/3 > > Looks good to me. The only remarks I have are: > * A nit pick: personally I would call the second argument of > ANNOTATE_BARRIER_INIT() "count" instead of "counter". > fixed > * Some barrier implementations (e.g. the one in libgomp) allow barrier > reinitialization while others (e.g. POSIX threads) do not allow this. > If we want threading tools to be able to complain about barrier > reinitialization for barrier types for which this is not allowed we > need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool > whether or not reinitialization is allowed. > hm. maybe. dunno. Usually, such checking is hacked into the implementation of the synchronization utlility itself... No? > > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2010-01-29 10:39:52
|
On Fri, Jan 29, 2010 at 11:33 AM, Konstantin Serebryany <kon...@gm...> wrote: > Please check here: http://codereview.appspot.com/196059/patch/1/3 Looks good to me. The only remarks I have are: * A nit pick: personally I would call the second argument of ANNOTATE_BARRIER_INIT() "count" instead of "counter". * Some barrier implementations (e.g. the one in libgomp) allow barrier reinitialization while others (e.g. POSIX threads) do not allow this. If we want threading tools to be able to complain about barrier reinitialization for barrier types for which this is not allowed we need a third argument for ANNOTATE_BARRIER_INIT() that tells the tool whether or not reinitialization is allowed. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2010-01-29 10:33:51
|
Please check here: http://codereview.appspot.com/196059/patch/1/3 On Fri, Jan 29, 2010 at 12:51 PM, Konstantin Serebryany < kon...@gm...> wrote: > > > On Fri, Jan 29, 2010 at 1:02 PM, Julian Seward <js...@ac...> wrote: > >> On Friday 29 January 2010, Konstantin Serebryany wrote: >> > And of course, we need 3 annotations: >> > >> > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n) >> > ANNOTATE_CYCLIC_BARRIER_WAIT_BEFORE(obj) >> > ANNOTATE_CYCLIC_BARRIER_WAIT_AFTER(obj) >> >> Ok, but .. couldn't we get rid of the "CYCLIC" bit? Barriers are >> widely understood to be cyclic. Just seems like pointless redundancy. >> > 2:1 > I give up. :) > >> >> Also, I would like to add >> >> ANNOTATE_BARRIER_DESTROY(obj) >> > > Yep. > Not that is reeeeeally badly required for the implementation, but nice for > consistency. > So, we end up with > ANNOTATE_BARRIER_INIT(obj, n) > ANNOTATE_BARRIER_WAIT_BEFORE(obj) > ANNOTATE_BARRIER_WAIT_AFTER(obj) > ANNOTATE_BARRIER_DESTROY(obj) > > --kcc > > >> >> so that a tool can observe the entire lifetime of a barrier if >> required. And so that the same annotations can be used to instrument >> custom barriers and pthread_barriers. >> >> J >> >> > >> > Here are the relevant bits of tsan code to support them: >> > >> --------------------------------------------------------------------------- >> >--------------- // Support for Cyclic Barrier, e.g. pthread_barrier_t. >> > // We need to create (barrier_count-1)^2 h-b arcs between >> > // threads blocking on a barrier. We should not create any h-b arcs >> > // for two calls to barrier_wait if the barrier was reset between >> then. >> > struct CyclicBarrierInfo { >> > // The value given to barrier_init. >> > uint32_t barrier_count; >> > // How many times we may block on this barrier before resetting. >> > int32_t calls_before_reset; >> > }; >> > // Maps the barrier pointer to CyclicBarrierInfo. >> > typedef hash_map<uintptr_t, CyclicBarrierInfo> CyclicBarrierMap; >> > >> > CyclicBarrierInfo &GetCyclicBarrierInfo(uintptr_t barrier) { >> > if (cyclic_barrier_map_ == NULL) { >> > cyclic_barrier_map_ = new CyclicBarrierMap; >> > } >> > return (*cyclic_barrier_map_)[barrier]; >> > } >> > >> > void HandleBarrierInit(uintptr_t barrier, uint32_t n) { >> > CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier); >> > info.barrier_count = n; >> > info.calls_before_reset = 0; >> > } >> > >> > void HandleBarrierWaitBefore(uintptr_t barrier) { >> > CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier); >> > >> > CHECK(info.calls_before_reset >= 0); >> > if (info.calls_before_reset == 0) { >> > // We are blocking the first time after reset. Clear the VTS. >> > info.calls_before_reset = info.barrier_count; >> > Signaller &signaller = (*signaller_map_)[barrier]; >> > VTS::Delete(signaller.vts); >> > signaller.vts = NULL; >> > } >> > info.calls_before_reset--; >> > // Signal to all threads that blocked on this barrier. >> > HandleSignal(barrier); >> > } >> > >> > void HandleBarrierWaitAfter(uintptr_t barrier) { >> > HandleWait(barrier, 0, false); >> > } >> > >> --------------------------------------------------------------------------- >> >--------------- Here is the report: >> > ==5414== WARNING: Expected data race during write of size 4 at >> 0xC968EE0: >> > {{{ >> > ==5414== T7 (locks held: {}): >> > ==5414== #0 PositiveTests_CyclicBarrierTest::b1() >> > /home/kcc/drt/trunk/unittest/posix_tests.cc:726 >> > ==5414== #1 MyThread::ThreadBody(MyThread*) >> > /home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328 >> > ==5414== #2 ThreadSanitizerStartThread >> > /home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535 >> > ==5414== Concurrent write(s) happened at (OR AFTER) these points: >> > ==5414== T4 (locks held: {}): >> > ==5414== #0 PositiveTests_CyclicBarrierTest::a1() >> > /home/kcc/drt/trunk/unittest/posix_tests.cc:712 >> > ==5414== #1 MyThread::ThreadBody(MyThread*) >> > /home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328 >> > ==5414== #2 ThreadSanitizerStartThread >> > /home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535 >> > ==5414== Address 0xC968EE0 is 0 bytes inside data symbol >> > "_ZN31PositiveTests_CyclicBarrierTest1LE" >> > ==5414== Description: "real race, may be hidden by incorrect >> > implementation of barrier" >> > ==5414== }}} >> > >> > >> > >> > --kcc >> > >> > >> > >> > >> > >> > >> > >> > On Fri, Jan 29, 2010 at 10:15 AM, Konstantin Serebryany < >> > >> > kon...@gm...> wrote: >> > > On Fri, Jan 29, 2010 at 10:12 AM, Bart Van Assche >> <bva...@ac...>wrote: >> > >> On Thu, Jan 28, 2010 at 8:17 PM, Konstantin Serebryany >> > >> >> > >> <kon...@gm...> wrote: >> > >> > I again forgot that pthread_barrier is cyclic (resettable). >> > >> > imho this is error prone and dull, but that's what we have. >> > >> > I think we will need two annotations to fully support it: >> > >> > // inserted before the actual barrier_init code >> > >> > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n) >> > >> > // inserted before the actual barrier_wait code. >> > >> > ANNOTATE_CYCLIC_BARRIER_WAIT(obj) >> > >> >> > >> Hello Konstantin, >> > >> >> > >> Why do feel that there is a need to tell a thread-checking tool on >> > >> beforehand whether a barrier will be used only once or multiple times >> > > >> > > There is not such need. >> > > I think the name should contain 'CYCLIC' to make it clear that the >> > > annotation supports cyclic barriers. >> > > It will of course work with non-resettable barriers as well. >> > > >> > > --kcc >> > > >> > >> ? >> > >> >> > >> Bart. >> >> >> > |
|
From: Konstantin S. <kon...@gm...> - 2010-01-29 09:52:11
|
On Fri, Jan 29, 2010 at 1:02 PM, Julian Seward <js...@ac...> wrote:
> On Friday 29 January 2010, Konstantin Serebryany wrote:
> > And of course, we need 3 annotations:
> >
> > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n)
> > ANNOTATE_CYCLIC_BARRIER_WAIT_BEFORE(obj)
> > ANNOTATE_CYCLIC_BARRIER_WAIT_AFTER(obj)
>
> Ok, but .. couldn't we get rid of the "CYCLIC" bit? Barriers are
> widely understood to be cyclic. Just seems like pointless redundancy.
>
2:1
I give up. :)
>
> Also, I would like to add
>
> ANNOTATE_BARRIER_DESTROY(obj)
>
Yep.
Not that is reeeeeally badly required for the implementation, but nice for
consistency.
So, we end up with
ANNOTATE_BARRIER_INIT(obj, n)
ANNOTATE_BARRIER_WAIT_BEFORE(obj)
ANNOTATE_BARRIER_WAIT_AFTER(obj)
ANNOTATE_BARRIER_DESTROY(obj)
--kcc
>
> so that a tool can observe the entire lifetime of a barrier if
> required. And so that the same annotations can be used to instrument
> custom barriers and pthread_barriers.
>
> J
>
> >
> > Here are the relevant bits of tsan code to support them:
> >
> ---------------------------------------------------------------------------
> >--------------- // Support for Cyclic Barrier, e.g. pthread_barrier_t.
> > // We need to create (barrier_count-1)^2 h-b arcs between
> > // threads blocking on a barrier. We should not create any h-b arcs
> > // for two calls to barrier_wait if the barrier was reset between then.
> > struct CyclicBarrierInfo {
> > // The value given to barrier_init.
> > uint32_t barrier_count;
> > // How many times we may block on this barrier before resetting.
> > int32_t calls_before_reset;
> > };
> > // Maps the barrier pointer to CyclicBarrierInfo.
> > typedef hash_map<uintptr_t, CyclicBarrierInfo> CyclicBarrierMap;
> >
> > CyclicBarrierInfo &GetCyclicBarrierInfo(uintptr_t barrier) {
> > if (cyclic_barrier_map_ == NULL) {
> > cyclic_barrier_map_ = new CyclicBarrierMap;
> > }
> > return (*cyclic_barrier_map_)[barrier];
> > }
> >
> > void HandleBarrierInit(uintptr_t barrier, uint32_t n) {
> > CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier);
> > info.barrier_count = n;
> > info.calls_before_reset = 0;
> > }
> >
> > void HandleBarrierWaitBefore(uintptr_t barrier) {
> > CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier);
> >
> > CHECK(info.calls_before_reset >= 0);
> > if (info.calls_before_reset == 0) {
> > // We are blocking the first time after reset. Clear the VTS.
> > info.calls_before_reset = info.barrier_count;
> > Signaller &signaller = (*signaller_map_)[barrier];
> > VTS::Delete(signaller.vts);
> > signaller.vts = NULL;
> > }
> > info.calls_before_reset--;
> > // Signal to all threads that blocked on this barrier.
> > HandleSignal(barrier);
> > }
> >
> > void HandleBarrierWaitAfter(uintptr_t barrier) {
> > HandleWait(barrier, 0, false);
> > }
> >
> ---------------------------------------------------------------------------
> >--------------- Here is the report:
> > ==5414== WARNING: Expected data race during write of size 4 at 0xC968EE0:
> > {{{
> > ==5414== T7 (locks held: {}):
> > ==5414== #0 PositiveTests_CyclicBarrierTest::b1()
> > /home/kcc/drt/trunk/unittest/posix_tests.cc:726
> > ==5414== #1 MyThread::ThreadBody(MyThread*)
> > /home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328
> > ==5414== #2 ThreadSanitizerStartThread
> > /home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535
> > ==5414== Concurrent write(s) happened at (OR AFTER) these points:
> > ==5414== T4 (locks held: {}):
> > ==5414== #0 PositiveTests_CyclicBarrierTest::a1()
> > /home/kcc/drt/trunk/unittest/posix_tests.cc:712
> > ==5414== #1 MyThread::ThreadBody(MyThread*)
> > /home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328
> > ==5414== #2 ThreadSanitizerStartThread
> > /home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535
> > ==5414== Address 0xC968EE0 is 0 bytes inside data symbol
> > "_ZN31PositiveTests_CyclicBarrierTest1LE"
> > ==5414== Description: "real race, may be hidden by incorrect
> > implementation of barrier"
> > ==5414== }}}
> >
> >
> >
> > --kcc
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jan 29, 2010 at 10:15 AM, Konstantin Serebryany <
> >
> > kon...@gm...> wrote:
> > > On Fri, Jan 29, 2010 at 10:12 AM, Bart Van Assche
> <bva...@ac...>wrote:
> > >> On Thu, Jan 28, 2010 at 8:17 PM, Konstantin Serebryany
> > >>
> > >> <kon...@gm...> wrote:
> > >> > I again forgot that pthread_barrier is cyclic (resettable).
> > >> > imho this is error prone and dull, but that's what we have.
> > >> > I think we will need two annotations to fully support it:
> > >> > // inserted before the actual barrier_init code
> > >> > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n)
> > >> > // inserted before the actual barrier_wait code.
> > >> > ANNOTATE_CYCLIC_BARRIER_WAIT(obj)
> > >>
> > >> Hello Konstantin,
> > >>
> > >> Why do feel that there is a need to tell a thread-checking tool on
> > >> beforehand whether a barrier will be used only once or multiple times
> > >
> > > There is not such need.
> > > I think the name should contain 'CYCLIC' to make it clear that the
> > > annotation supports cyclic barriers.
> > > It will of course work with non-resettable barriers as well.
> > >
> > > --kcc
> > >
> > >> ?
> > >>
> > >> Bart.
>
>
>
|
|
From: Julian S. <js...@ac...> - 2010-01-29 09:48:25
|
On Friday 29 January 2010, Konstantin Serebryany wrote:
> And of course, we need 3 annotations:
>
> ANNOTATE_CYCLIC_BARRIER_INIT(obj, n)
> ANNOTATE_CYCLIC_BARRIER_WAIT_BEFORE(obj)
> ANNOTATE_CYCLIC_BARRIER_WAIT_AFTER(obj)
Ok, but .. couldn't we get rid of the "CYCLIC" bit? Barriers are
widely understood to be cyclic. Just seems like pointless redundancy.
Also, I would like to add
ANNOTATE_BARRIER_DESTROY(obj)
so that a tool can observe the entire lifetime of a barrier if
required. And so that the same annotations can be used to instrument
custom barriers and pthread_barriers.
J
>
> Here are the relevant bits of tsan code to support them:
> ---------------------------------------------------------------------------
>--------------- // Support for Cyclic Barrier, e.g. pthread_barrier_t.
> // We need to create (barrier_count-1)^2 h-b arcs between
> // threads blocking on a barrier. We should not create any h-b arcs
> // for two calls to barrier_wait if the barrier was reset between then.
> struct CyclicBarrierInfo {
> // The value given to barrier_init.
> uint32_t barrier_count;
> // How many times we may block on this barrier before resetting.
> int32_t calls_before_reset;
> };
> // Maps the barrier pointer to CyclicBarrierInfo.
> typedef hash_map<uintptr_t, CyclicBarrierInfo> CyclicBarrierMap;
>
> CyclicBarrierInfo &GetCyclicBarrierInfo(uintptr_t barrier) {
> if (cyclic_barrier_map_ == NULL) {
> cyclic_barrier_map_ = new CyclicBarrierMap;
> }
> return (*cyclic_barrier_map_)[barrier];
> }
>
> void HandleBarrierInit(uintptr_t barrier, uint32_t n) {
> CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier);
> info.barrier_count = n;
> info.calls_before_reset = 0;
> }
>
> void HandleBarrierWaitBefore(uintptr_t barrier) {
> CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier);
>
> CHECK(info.calls_before_reset >= 0);
> if (info.calls_before_reset == 0) {
> // We are blocking the first time after reset. Clear the VTS.
> info.calls_before_reset = info.barrier_count;
> Signaller &signaller = (*signaller_map_)[barrier];
> VTS::Delete(signaller.vts);
> signaller.vts = NULL;
> }
> info.calls_before_reset--;
> // Signal to all threads that blocked on this barrier.
> HandleSignal(barrier);
> }
>
> void HandleBarrierWaitAfter(uintptr_t barrier) {
> HandleWait(barrier, 0, false);
> }
> ---------------------------------------------------------------------------
>--------------- Here is the report:
> ==5414== WARNING: Expected data race during write of size 4 at 0xC968EE0:
> {{{
> ==5414== T7 (locks held: {}):
> ==5414== #0 PositiveTests_CyclicBarrierTest::b1()
> /home/kcc/drt/trunk/unittest/posix_tests.cc:726
> ==5414== #1 MyThread::ThreadBody(MyThread*)
> /home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328
> ==5414== #2 ThreadSanitizerStartThread
> /home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535
> ==5414== Concurrent write(s) happened at (OR AFTER) these points:
> ==5414== T4 (locks held: {}):
> ==5414== #0 PositiveTests_CyclicBarrierTest::a1()
> /home/kcc/drt/trunk/unittest/posix_tests.cc:712
> ==5414== #1 MyThread::ThreadBody(MyThread*)
> /home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328
> ==5414== #2 ThreadSanitizerStartThread
> /home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535
> ==5414== Address 0xC968EE0 is 0 bytes inside data symbol
> "_ZN31PositiveTests_CyclicBarrierTest1LE"
> ==5414== Description: "real race, may be hidden by incorrect
> implementation of barrier"
> ==5414== }}}
>
>
>
> --kcc
>
>
>
>
>
>
>
> On Fri, Jan 29, 2010 at 10:15 AM, Konstantin Serebryany <
>
> kon...@gm...> wrote:
> > On Fri, Jan 29, 2010 at 10:12 AM, Bart Van Assche
<bva...@ac...>wrote:
> >> On Thu, Jan 28, 2010 at 8:17 PM, Konstantin Serebryany
> >>
> >> <kon...@gm...> wrote:
> >> > I again forgot that pthread_barrier is cyclic (resettable).
> >> > imho this is error prone and dull, but that's what we have.
> >> > I think we will need two annotations to fully support it:
> >> > // inserted before the actual barrier_init code
> >> > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n)
> >> > // inserted before the actual barrier_wait code.
> >> > ANNOTATE_CYCLIC_BARRIER_WAIT(obj)
> >>
> >> Hello Konstantin,
> >>
> >> Why do feel that there is a need to tell a thread-checking tool on
> >> beforehand whether a barrier will be used only once or multiple times
> >
> > There is not such need.
> > I think the name should contain 'CYCLIC' to make it clear that the
> > annotation supports cyclic barriers.
> > It will of course work with non-resettable barriers as well.
> >
> > --kcc
> >
> >> ?
> >>
> >> Bart.
|
|
From: Bart V. A. <bva...@ac...> - 2010-01-29 09:46:39
|
On Fri, Jan 29, 2010 at 8:15 AM, Konstantin Serebryany <kon...@gm...> wrote: > > On Fri, Jan 29, 2010 at 10:12 AM, Bart Van Assche <bva...@ac...> > wrote: >> >> On Thu, Jan 28, 2010 at 8:17 PM, Konstantin Serebryany >> <kon...@gm...> wrote: >> > I again forgot that pthread_barrier is cyclic (resettable). >> > imho this is error prone and dull, but that's what we have. >> > I think we will need two annotations to fully support it: >> > // inserted before the actual barrier_init code >> > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n) >> > // inserted before the actual barrier_wait code. >> > ANNOTATE_CYCLIC_BARRIER_WAIT(obj) >> >> Hello Konstantin, >> >> Why do feel that there is a need to tell a thread-checking tool on >> beforehand whether a barrier will be used only once or multiple times > > There is not such need. > I think the name should contain 'CYCLIC' to make it clear that the > annotation supports cyclic barriers. > It will of course work with non-resettable barriers as well. As far as I know the term 'cyclic barrier' is only used in the context of the Java programming language and not in any document about POSIX barriers. So this terminology might be confusing for who's familiar with POSIX threads but not with Java. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2010-01-29 09:39:09
|
And of course, we need 3 annotations:
ANNOTATE_CYCLIC_BARRIER_INIT(obj, n)
ANNOTATE_CYCLIC_BARRIER_WAIT_BEFORE(obj)
ANNOTATE_CYCLIC_BARRIER_WAIT_AFTER(obj)
Here are the relevant bits of tsan code to support them:
------------------------------------------------------------------------------------------
// Support for Cyclic Barrier, e.g. pthread_barrier_t.
// We need to create (barrier_count-1)^2 h-b arcs between
// threads blocking on a barrier. We should not create any h-b arcs
// for two calls to barrier_wait if the barrier was reset between then.
struct CyclicBarrierInfo {
// The value given to barrier_init.
uint32_t barrier_count;
// How many times we may block on this barrier before resetting.
int32_t calls_before_reset;
};
// Maps the barrier pointer to CyclicBarrierInfo.
typedef hash_map<uintptr_t, CyclicBarrierInfo> CyclicBarrierMap;
CyclicBarrierInfo &GetCyclicBarrierInfo(uintptr_t barrier) {
if (cyclic_barrier_map_ == NULL) {
cyclic_barrier_map_ = new CyclicBarrierMap;
}
return (*cyclic_barrier_map_)[barrier];
}
void HandleBarrierInit(uintptr_t barrier, uint32_t n) {
CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier);
info.barrier_count = n;
info.calls_before_reset = 0;
}
void HandleBarrierWaitBefore(uintptr_t barrier) {
CyclicBarrierInfo &info = GetCyclicBarrierInfo(barrier);
CHECK(info.calls_before_reset >= 0);
if (info.calls_before_reset == 0) {
// We are blocking the first time after reset. Clear the VTS.
info.calls_before_reset = info.barrier_count;
Signaller &signaller = (*signaller_map_)[barrier];
VTS::Delete(signaller.vts);
signaller.vts = NULL;
}
info.calls_before_reset--;
// Signal to all threads that blocked on this barrier.
HandleSignal(barrier);
}
void HandleBarrierWaitAfter(uintptr_t barrier) {
HandleWait(barrier, 0, false);
}
------------------------------------------------------------------------------------------
Here is the report:
==5414== WARNING: Expected data race during write of size 4 at 0xC968EE0:
{{{
==5414== T7 (locks held: {}):
==5414== #0 PositiveTests_CyclicBarrierTest::b1()
/home/kcc/drt/trunk/unittest/posix_tests.cc:726
==5414== #1 MyThread::ThreadBody(MyThread*)
/home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328
==5414== #2 ThreadSanitizerStartThread
/home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535
==5414== Concurrent write(s) happened at (OR AFTER) these points:
==5414== T4 (locks held: {}):
==5414== #0 PositiveTests_CyclicBarrierTest::a1()
/home/kcc/drt/trunk/unittest/posix_tests.cc:712
==5414== #1 MyThread::ThreadBody(MyThread*)
/home/kcc/drt/trunk/unittest/thread_wrappers_pthread.h:328
==5414== #2 ThreadSanitizerStartThread
/home/kcc/drt/trunk/tsan/ts_valgrind_intercepts.c:535
==5414== Address 0xC968EE0 is 0 bytes inside data symbol
"_ZN31PositiveTests_CyclicBarrierTest1LE"
==5414== Description: "real race, may be hidden by incorrect implementation
of barrier"
==5414== }}}
--kcc
On Fri, Jan 29, 2010 at 10:15 AM, Konstantin Serebryany <
kon...@gm...> wrote:
>
>
> On Fri, Jan 29, 2010 at 10:12 AM, Bart Van Assche <bva...@ac...>wrote:
>
>> On Thu, Jan 28, 2010 at 8:17 PM, Konstantin Serebryany
>> <kon...@gm...> wrote:
>> > I again forgot that pthread_barrier is cyclic (resettable).
>> > imho this is error prone and dull, but that's what we have.
>> > I think we will need two annotations to fully support it:
>> > // inserted before the actual barrier_init code
>> > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n)
>> > // inserted before the actual barrier_wait code.
>> > ANNOTATE_CYCLIC_BARRIER_WAIT(obj)
>>
>> Hello Konstantin,
>>
>> Why do feel that there is a need to tell a thread-checking tool on
>> beforehand whether a barrier will be used only once or multiple times
>>
>
> There is not such need.
> I think the name should contain 'CYCLIC' to make it clear that the
> annotation supports cyclic barriers.
> It will of course work with non-resettable barriers as well.
>
> --kcc
>
>
>> ?
>>
>> Bart.
>>
>
>
|
|
From: Alexander P. <gl...@go...> - 2010-01-29 07:59:23
|
Nightly build on mcgrind ( Darwin 9.7.0 i386 ) Started at 2010-01-29 09:06:01 MSK Ended at 2010-01-29 09:25:11 MSK Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 433 tests, 22 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/null_socket (stdout) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) none/tests/async-sigs (stderr) none/tests/faultstatus (stderr) none/tests/pth_blockedsig (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc23_bogus_condwait (stderr) -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Bart V. A. <bar...@gm...> - 2010-01-29 07:32:06
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2010-01-29 02:28:52 EST Ended at 2010-01-29 02:31:53 EST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-29T02:28:52} valgrind-new Job ID = 193.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory Configuring valgrind ... cd valgrind-new && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-new/Inst Job ID = 194.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory Building valgrind ... cd valgrind-new && make -j 2 && make -j 2 check && make install Job ID = 195.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory Running regression tests ... cd valgrind-new && make regtest Job ID = 196.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-28T02:28:52} valgrind-old Job ID = 189.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory Configuring valgrind ... cd valgrind-old && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-old/Inst Job ID = 190.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory Building valgrind ... cd valgrind-old && make -j 2 && make -j 2 check && make install Job ID = 191.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory Running regression tests ... cd valgrind-old && make regtest Job ID = 192.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Jan 29 02:31:12 2010 --- new.short Fri Jan 29 02:31:53 2010 *************** *** 8,20 **** ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-28T02:28:52} valgrind-old ! Job ID = 189.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ! Configuring valgrind ... cd valgrind-old && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-old/Inst ! Job ID = 190.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ! Building valgrind ... cd valgrind-old && make -j 2 && make -j 2 check && make install ! Job ID = 191.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ! Running regression tests ... cd valgrind-old && make regtest ! Job ID = 192.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory --- 8,20 ---- ! Checking out valgrind source tree ... svn co svn://svn.valgrind.org/valgrind/trunk -r {2010-01-29T02:28:52} valgrind-new ! Job ID = 193.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ! Configuring valgrind ... cd valgrind-new && ./autogen.sh && ./configure --prefix=/home/bart/software/valgrind/nightly/valgrind-new/Inst ! Job ID = 194.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ! Building valgrind ... cd valgrind-new && make -j 2 && make -j 2 check && make install ! Job ID = 195.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory ! Running regression tests ... cd valgrind-new && make regtest ! Job ID = 196.cell-user.cell.buzz cat: cmd-output.txt: No such file or directory |
|
From: Konstantin S. <kon...@gm...> - 2010-01-29 07:15:32
|
On Fri, Jan 29, 2010 at 10:12 AM, Bart Van Assche <bva...@ac...>wrote: > On Thu, Jan 28, 2010 at 8:17 PM, Konstantin Serebryany > <kon...@gm...> wrote: > > I again forgot that pthread_barrier is cyclic (resettable). > > imho this is error prone and dull, but that's what we have. > > I think we will need two annotations to fully support it: > > // inserted before the actual barrier_init code > > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n) > > // inserted before the actual barrier_wait code. > > ANNOTATE_CYCLIC_BARRIER_WAIT(obj) > > Hello Konstantin, > > Why do feel that there is a need to tell a thread-checking tool on > beforehand whether a barrier will be used only once or multiple times > There is not such need. I think the name should contain 'CYCLIC' to make it clear that the annotation supports cyclic barriers. It will of course work with non-resettable barriers as well. --kcc > ? > > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2010-01-29 07:12:41
|
On Thu, Jan 28, 2010 at 8:17 PM, Konstantin Serebryany <kon...@gm...> wrote: > I again forgot that pthread_barrier is cyclic (resettable). > imho this is error prone and dull, but that's what we have. > I think we will need two annotations to fully support it: > // inserted before the actual barrier_init code > ANNOTATE_CYCLIC_BARRIER_INIT(obj, n) > // inserted before the actual barrier_wait code. > ANNOTATE_CYCLIC_BARRIER_WAIT(obj) Hello Konstantin, Why do feel that there is a need to tell a thread-checking tool on beforehand whether a barrier will be used only once or multiple times ? Bart. |
|
From: Tom H. <th...@cy...> - 2010-01-29 03:50:12
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-01-29 03:05:08 GMT Ended at 2010-01-29 03:49:59 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-01-29 03:35:47
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-01-29 03:10:04 GMT Ended at 2010-01-29 03:35:28 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |