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
(9) |
|
2
(12) |
3
(19) |
4
(18) |
5
(22) |
6
(25) |
7
(18) |
8
(24) |
|
9
(16) |
10
(15) |
11
(22) |
12
(7) |
13
(19) |
14
(5) |
15
(8) |
|
16
(7) |
17
(8) |
18
(9) |
19
(7) |
20
(13) |
21
(16) |
22
(7) |
|
23
(10) |
24
(8) |
25
(4) |
26
(4) |
27
(9) |
28
(4) |
29
(5) |
|
30
(8) |
31
(4) |
|
|
|
|
|
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 15:41:59
|
Yep, that's it. On Dec 13, 2007 12:30 PM, Julian Seward <js...@ac...> wrote: > > I believe this to be a limitation of the Eraser algorithm. See > last para of Section 2.2 of > http://citeseer.ist.psu.edu/savage97eraser.html, > "Our support for initialization ..." > > J > > > On Thursday 13 December 2007 09:12, Konstantin Serebryany wrote: > > Julian, all, any ideas on this? > > [ I am sorry for disturbing you... But just in case you've missed this > > message...] > > > > --kcc > > > > On Dec 6, 2007 12:23 PM, Konstantin Serebryany > > <kon...@gm...> > > > > wrote: > > > Hi > > > One more question: > > > > > > > > > % cat missed_race.cc > > > #include <pthread.h> > > > #include <stdio.h> > > > #include <unistd.h> > > > // In this test we do the following: > > > // parent...........................worker > > > // 1. pthread_create(worker) a. sleep(sleep_worker) > > > // 2. sleep(sleep_parent) b. print(GLOB) > > > // 3. GLOB = 1 > > > > > > // The behaviour of helgrind depends on values of > > > // sleep_parent/sleep_worker. > > > // If the values are close (sleep_parent=1000, sleep_worker=2000), > > > // detection of the race actually depends on luck. > > > // On my system it is detected 1 of 4-5 of times. > > > // > > > // If the parent gets to 'GLOB=1' first, then no race is detected. > > > // We have Exclusive(parent)->ShR(parent,worker) > > > // > > > // If the worker gets to print(GLOB) first, then the race is reported. > > > // We have Exclusive(worked)->ShM({parent,worker}, {empty lockset}) > > > // > > > // This race should (IMHO) be detected independently of sleep values. > > > // Do we need to have ExclusiveR and ExclusiveW instead of just > > > Exclusive? > > > > > > int GLOB = 0; > > > const int sleep_parent=1000; > > > const int sleep_worker=2000; > > > > > > void *worker(void*) > > > { > > > usleep(sleep_worker); > > > printf("GLOB=%d\n", GLOB); > > > return NULL; > > > } > > > int main(int argc, char **argv) > > > { > > > pthread_t threadid; > > > pthread_create(&threadid, NULL, worker, NULL); > > > usleep(sleep_parent); > > > GLOB = 1; > > > pthread_join(threadid, NULL); > > > } > > > > > > /* > > > % g++ -g missed_race.cc -lpthread > > > % for((i=1; i <= 10; i++)); do echo ---------- $i; > > > ~/race/valgrind32orig/Inst/bin/valgrind -q --tool=helgrind ./a.out > 2>&1 > > > | grep -A 5 Possible; done > > > ---------- 1 > > > ---------- 2 > > > ---------- 3 > > > ---------- 4 > > > ---------- 5 > > > ---------- 6 > > > ==13246== Possible data race during write of size 4 at 0x8049850 > > > ==13246== at 0x8048585: main (missed_race.cc:40) > > > ==13246== Old state: owned exclusively by thread #2 > > > ==13246== New state: shared-modified by threads #1, #2 > > > ==13246== Reason: this thread, #1, holds no locks at all > > > GLOB=0 > > > ---------- 7 > > > ---------- 8 > > > ==13254== Possible data race during write of size 4 at 0x8049850 > > > ==13254== at 0x8048585: main (missed_race.cc:40) > > > ==13254== Old state: owned exclusively by thread #2 > > > ==13254== New state: shared-modified by threads #1, #2 > > > ==13254== Reason: this thread, #1, holds no locks at all > > > GLOB=0 > > > ---------- 9 > > > ---------- 10 > > > % > > > */ > |
|
From: Julian S. <js...@ac...> - 2007-12-13 13:57:44
|
> On Dec 13, 2007 3:12 PM, Konstantin Serebryany < > > kon...@gm...> wrote: > > I tried this patch with a test where multiple workers are present -- it > > does not help. :( > > Or is this another problem? > > another test attached. Yes. I can see what is happening and am considering a more general and better fix. However, that will take some days I think. Thanks for the example(s). J |
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 12:36:01
|
In msm__handle_write under if (is_SHVAL_ShR(wold)) { we don't check
happens_before...
We can't, because when we are in ShR we don't have SegmentIDs...
On Dec 13, 2007 3:12 PM, Konstantin Serebryany <
kon...@gm...> wrote:
> I tried this patch with a test where multiple workers are present -- it
> does not help. :(
> Or is this another problem?
> another test attached.
>
> --kcc
>
> --kcc
> #include <pthread.h>
> #include < stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <assert.h>
> // This test is race-free,
> // but helgrind 3.3.0 reports a race iff n_workers >= 2.
> //
> // main worker1,worker2,...,workerN
> //
> // 1. start(all workers)
> // a. read(GLOB)
> // /----------b. signal(CV)
> // 2. wait(CV) <-----/
> // 3. write(GLOB)
> static int COND = 0;
> static int GLOB = 0;
> static pthread_cond_t CV = PTHREAD_COND_INITIALIZER;
> static pthread_mutex_t MU = PTHREAD_MUTEX_INITIALIZER;
>
> void *run_pm(void*) {
> sleep(2); // we want waiter to get there first
> int val = GLOB;
> pthread_mutex_lock(&MU);
> COND++;
> fprintf(stderr, "Signaling: COND: %d; val=%d\n", COND, val);
> pthread_cond_signal(&CV);
> pthread_mutex_unlock(&MU);
> return NULL;
> }
>
> int main(int argc, char **argv) {
> pthread_t threads[100];
> int n_workers = argc == 2 ? atoi(argv[1]) : 2;
>
> for (int i = 0; i < n_workers; i++) {
> pthread_create(&threads[i], NULL, run_pm, NULL);
> }
>
> bool entered_cond_wait = false;
>
> pthread_mutex_lock(&MU);
> while (COND != n_workers) {
> entered_cond_wait = true;
> printf("Blocking: COND=%d\n", COND);
> pthread_cond_wait(&CV, &MU);
> printf("Waking: COND=%d\n", COND);
> }
> pthread_mutex_unlock(&MU);
>
> assert(COND == n_workers); // being paranoid
> assert(entered_cond_wait); // because otherwise is unfair
>
> GLOB = 2; // race is reported here
>
> fprintf(stderr, "GLOB: %d\n", GLOB);
> for (int i = 0; i < n_workers; i++) {
> pthread_join(threads[i], NULL);
> }
> return 0;
>
> }
>
>
>
> On Dec 13, 2007 12:24 PM, Julian Seward <js...@ac...> wrote:
>
> > On Thursday 13 December 2007 09:07, Konstantin Serebryany wrote:
> > > But isn't it expensive?
> > >
> > > On Dec 13, 2007 11:01 AM, Julian Seward < js...@ac...> wrote:
> > > > On Thursday 13 December 2007 08:44, Konstantin Serebryany wrote:
> > > > > Hi,
> > > > >
> > > > > The same false positive appears when mixing mutexes and
> > semaphores.
> > > > > Test attached.
> > > > > As with cond vars, we are able to transition Excl(T1)->Excl(T2),
> > but
> > > > > can not do ShM(T1,T2)->Excl(T2).
> > > > >
> > > > > As I understand, fixing this properly will require storing
> > SegmentID in
> > > >
> > > > all
> > > >
> > > > > shadow words, not only in those that are in Exclusive state.
> > > > > This will hardly squeeze into 32 bits though, need 64... :(
> > > >
> > > > No, I don't think so. We just need to do the same memory ownership
> > > > transition for semaphores that the "cvhack" patch does for CVs.
> > I'll
> > > > extend the current patch.
> >
> > Here is version 2 of the cvhack patch. This makes your semaphore test
> > run clean (with --happens-before=cvhack).
> >
> > J
> >
> >
> >
>
|
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 12:12:35
|
I tried this patch with a test where multiple workers are present -- it does
not help. :(
Or is this another problem?
another test attached.
--kcc
--kcc
#include <pthread.h>
#include < stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <assert.h>
// This test is race-free,
// but helgrind 3.3.0 reports a race iff n_workers >= 2.
//
// main worker1,worker2,...,workerN
//
// 1. start(all workers)
// a. read(GLOB)
// /----------b. signal(CV)
// 2. wait(CV) <-----/
// 3. write(GLOB)
static int COND = 0;
static int GLOB = 0;
static pthread_cond_t CV = PTHREAD_COND_INITIALIZER;
static pthread_mutex_t MU = PTHREAD_MUTEX_INITIALIZER;
void *run_pm(void*) {
sleep(2); // we want waiter to get there first
int val = GLOB;
pthread_mutex_lock(&MU);
COND++;
fprintf(stderr, "Signaling: COND: %d; val=%d\n", COND, val);
pthread_cond_signal(&CV);
pthread_mutex_unlock(&MU);
return NULL;
}
int main(int argc, char **argv) {
pthread_t threads[100];
int n_workers = argc == 2 ? atoi(argv[1]) : 2;
for (int i = 0; i < n_workers; i++) {
pthread_create(&threads[i], NULL, run_pm, NULL);
}
bool entered_cond_wait = false;
pthread_mutex_lock(&MU);
while (COND != n_workers) {
entered_cond_wait = true;
printf("Blocking: COND=%d\n", COND);
pthread_cond_wait(&CV, &MU);
printf("Waking: COND=%d\n", COND);
}
pthread_mutex_unlock(&MU);
assert(COND == n_workers); // being paranoid
assert(entered_cond_wait); // because otherwise is unfair
GLOB = 2; // race is reported here
fprintf(stderr, "GLOB: %d\n", GLOB);
for (int i = 0; i < n_workers; i++) {
pthread_join(threads[i], NULL);
}
return 0;
}
On Dec 13, 2007 12:24 PM, Julian Seward <js...@ac...> wrote:
> On Thursday 13 December 2007 09:07, Konstantin Serebryany wrote:
> > But isn't it expensive?
> >
> > On Dec 13, 2007 11:01 AM, Julian Seward < js...@ac...> wrote:
> > > On Thursday 13 December 2007 08:44, Konstantin Serebryany wrote:
> > > > Hi,
> > > >
> > > > The same false positive appears when mixing mutexes and semaphores.
> > > > Test attached.
> > > > As with cond vars, we are able to transition Excl(T1)->Excl(T2), but
> > > > can not do ShM(T1,T2)->Excl(T2).
> > > >
> > > > As I understand, fixing this properly will require storing SegmentID
> in
> > >
> > > all
> > >
> > > > shadow words, not only in those that are in Exclusive state.
> > > > This will hardly squeeze into 32 bits though, need 64... :(
> > >
> > > No, I don't think so. We just need to do the same memory ownership
> > > transition for semaphores that the "cvhack" patch does for CVs. I'll
> > > extend the current patch.
>
> Here is version 2 of the cvhack patch. This makes your semaphore test
> run clean (with --happens-before=cvhack).
>
> J
>
>
>
|
|
From: Tom H. <th...@cy...> - 2007-12-13 12:01:32
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-13 03:00:02 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 == 357 tests, 24 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Julian S. <js...@ac...> - 2007-12-13 11:27:32
|
On Thursday 13 December 2007 09:07, Konstantin Serebryany wrote: > But isn't it expensive? Potentially, yes in the naive implementation. But I can think of at least two other ways to make the transition cheaper. Those require more implementation effort though. J |
|
From: Julian S. <js...@ac...> - 2007-12-13 11:06:41
|
On Thursday 13 December 2007 08:44, Konstantin Serebryany wrote: > Hi, > > The same false positive appears when mixing mutexes and semaphores. Test > attached. > As with cond vars, we are able to transition Excl(T1)->Excl(T2), but can > not do ShM(T1,T2)->Excl(T2). > > As I understand, fixing this properly will require storing SegmentID in all > shadow words, not only in those that are in Exclusive state. > This will hardly squeeze into 32 bits though, need 64... :( No, I don't think so. We just need to do the same memory ownership transition for semaphores that the "cvhack" patch does for CVs. I'll extend the current patch. J |
|
From: Julian S. <js...@ac...> - 2007-12-13 10:10:38
|
On Thursday 13 December 2007 09:07, Konstantin Serebryany wrote: > But isn't it expensive? > > On Dec 13, 2007 11:01 AM, Julian Seward <js...@ac...> wrote: > > On Thursday 13 December 2007 08:44, Konstantin Serebryany wrote: > > > Hi, > > > > > > The same false positive appears when mixing mutexes and semaphores. > > > Test attached. > > > As with cond vars, we are able to transition Excl(T1)->Excl(T2), but > > > can not do ShM(T1,T2)->Excl(T2). > > > > > > As I understand, fixing this properly will require storing SegmentID in > > > > all > > > > > shadow words, not only in those that are in Exclusive state. > > > This will hardly squeeze into 32 bits though, need 64... :( > > > > No, I don't think so. We just need to do the same memory ownership > > transition for semaphores that the "cvhack" patch does for CVs. I'll > > extend the current patch. Here is version 2 of the cvhack patch. This makes your semaphore test run clean (with --happens-before=cvhack). J |
|
From: Julian S. <js...@ac...> - 2007-12-13 09:39:03
|
On Thursday 13 December 2007 09:30, Konstantin Serebryany wrote: > Your comment says: > Examine all ShM/ShR states in the system. For each one, look at ... > > This means that if we have lots of shared memory locations and lots of > condvar/semaphore events we are in trouble. > If we store SegmentIDs in shadow, we can do the same thing in a lazy > manner. No .. the lazy ownership transitions only happen for memory in Excl state. You have memory in shared states which you want to change to exclusive when a CV sig/wait or sem post/wait happen - the lazy mechanism will not deal with those, even if SegmentIDs were always attached. J |
|
From: Julian S. <js...@ac...> - 2007-12-13 09:31:54
|
I believe this to be a limitation of the Eraser algorithm. See last para of Section 2.2 of http://citeseer.ist.psu.edu/savage97eraser.html, "Our support for initialization ..." J On Thursday 13 December 2007 09:12, Konstantin Serebryany wrote: > Julian, all, any ideas on this? > [ I am sorry for disturbing you... But just in case you've missed this > message...] > > --kcc > > On Dec 6, 2007 12:23 PM, Konstantin Serebryany > <kon...@gm...> > > wrote: > > Hi > > One more question: > > > > > > % cat missed_race.cc > > #include <pthread.h> > > #include <stdio.h> > > #include <unistd.h> > > // In this test we do the following: > > // parent...........................worker > > // 1. pthread_create(worker) a. sleep(sleep_worker) > > // 2. sleep(sleep_parent) b. print(GLOB) > > // 3. GLOB = 1 > > > > // The behaviour of helgrind depends on values of > > // sleep_parent/sleep_worker. > > // If the values are close (sleep_parent=1000, sleep_worker=2000), > > // detection of the race actually depends on luck. > > // On my system it is detected 1 of 4-5 of times. > > // > > // If the parent gets to 'GLOB=1' first, then no race is detected. > > // We have Exclusive(parent)->ShR(parent,worker) > > // > > // If the worker gets to print(GLOB) first, then the race is reported. > > // We have Exclusive(worked)->ShM({parent,worker}, {empty lockset}) > > // > > // This race should (IMHO) be detected independently of sleep values. > > // Do we need to have ExclusiveR and ExclusiveW instead of just > > Exclusive? > > > > int GLOB = 0; > > const int sleep_parent=1000; > > const int sleep_worker=2000; > > > > void *worker(void*) > > { > > usleep(sleep_worker); > > printf("GLOB=%d\n", GLOB); > > return NULL; > > } > > int main(int argc, char **argv) > > { > > pthread_t threadid; > > pthread_create(&threadid, NULL, worker, NULL); > > usleep(sleep_parent); > > GLOB = 1; > > pthread_join(threadid, NULL); > > } > > > > /* > > % g++ -g missed_race.cc -lpthread > > % for((i=1; i <= 10; i++)); do echo ---------- $i; > > ~/race/valgrind32orig/Inst/bin/valgrind -q --tool=helgrind ./a.out 2>&1 > > | grep -A 5 Possible; done > > ---------- 1 > > ---------- 2 > > ---------- 3 > > ---------- 4 > > ---------- 5 > > ---------- 6 > > ==13246== Possible data race during write of size 4 at 0x8049850 > > ==13246== at 0x8048585: main (missed_race.cc:40) > > ==13246== Old state: owned exclusively by thread #2 > > ==13246== New state: shared-modified by threads #1, #2 > > ==13246== Reason: this thread, #1, holds no locks at all > > GLOB=0 > > ---------- 7 > > ---------- 8 > > ==13254== Possible data race during write of size 4 at 0x8049850 > > ==13254== at 0x8048585: main (missed_race.cc:40) > > ==13254== Old state: owned exclusively by thread #2 > > ==13254== New state: shared-modified by threads #1, #2 > > ==13254== Reason: this thread, #1, holds no locks at all > > GLOB=0 > > ---------- 9 > > ---------- 10 > > % > > */ |
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 08:36:43
|
Your comment says: Examine all ShM/ShR states in the system. For each one, look at ... This means that if we have lots of shared memory locations and lots of condvar/semaphore events we are in trouble. If we store SegmentIDs in shadow, we can do the same thing in a lazy manner. Again, just speculating... --kcc On Dec 13, 2007 11:20 AM, Julian Seward <js...@ac...> wrote: > On Thursday 13 December 2007 09:07, Konstantin Serebryany wrote: > > But isn't it expensive? > > Potentially, yes in the naive implementation. But I can think of at > least two other ways to make the transition cheaper. Those require > more implementation effort though. > > J > |
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 08:16:37
|
Just speculating, my understand of helgrind's algorithm is still poor ... May be we shall store SegementIDs in TSET's instead of ThreadIDs? On Dec 13, 2007 11:07 AM, Konstantin Serebryany < kon...@gm...> wrote: > But isn't it expensive? > > > On Dec 13, 2007 11:01 AM, Julian Seward <js...@ac...> wrote: > > > On Thursday 13 December 2007 08:44, Konstantin Serebryany wrote: > > > Hi, > > > > > > The same false positive appears when mixing mutexes and semaphores. > > Test > > > attached. > > > As with cond vars, we are able to transition Excl(T1)->Excl(T2), but > > can > > > not do ShM(T1,T2)->Excl(T2). > > > > > > As I understand, fixing this properly will require storing SegmentID > > in all > > > shadow words, not only in those that are in Exclusive state. > > > This will hardly squeeze into 32 bits though, need 64... :( > > > > No, I don't think so. We just need to do the same memory ownership > > transition for semaphores that the "cvhack" patch does for CVs. I'll > > extend the current patch. > > > > J > > > > |
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 08:14:28
|
But isn't it expensive? On Dec 13, 2007 11:01 AM, Julian Seward <js...@ac...> wrote: > On Thursday 13 December 2007 08:44, Konstantin Serebryany wrote: > > Hi, > > > > The same false positive appears when mixing mutexes and semaphores. Test > > attached. > > As with cond vars, we are able to transition Excl(T1)->Excl(T2), but can > > not do ShM(T1,T2)->Excl(T2). > > > > As I understand, fixing this properly will require storing SegmentID in > all > > shadow words, not only in those that are in Exclusive state. > > This will hardly squeeze into 32 bits though, need 64... :( > > No, I don't think so. We just need to do the same memory ownership > transition for semaphores that the "cvhack" patch does for CVs. I'll > extend the current patch. > > J > |
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 08:12:03
|
Julian, all, any ideas on this?
[ I am sorry for disturbing you... But just in case you've missed this
message...]
--kcc
On Dec 6, 2007 12:23 PM, Konstantin Serebryany
<kon...@gm...>
wrote:
> Hi
> One more question:
>
>
> % cat missed_race.cc
> #include <pthread.h>
> #include <stdio.h>
> #include <unistd.h>
> // In this test we do the following:
> // parent...........................worker
> // 1. pthread_create(worker) a. sleep(sleep_worker)
> // 2. sleep(sleep_parent) b. print(GLOB)
> // 3. GLOB = 1
>
> // The behaviour of helgrind depends on values of
> // sleep_parent/sleep_worker.
> // If the values are close (sleep_parent=1000, sleep_worker=2000),
> // detection of the race actually depends on luck.
> // On my system it is detected 1 of 4-5 of times.
> //
> // If the parent gets to 'GLOB=1' first, then no race is detected.
> // We have Exclusive(parent)->ShR(parent,worker)
> //
> // If the worker gets to print(GLOB) first, then the race is reported.
> // We have Exclusive(worked)->ShM({parent,worker}, {empty lockset})
> //
> // This race should (IMHO) be detected independently of sleep values.
> // Do we need to have ExclusiveR and ExclusiveW instead of just Exclusive?
>
> int GLOB = 0;
> const int sleep_parent=1000;
> const int sleep_worker=2000;
>
> void *worker(void*)
> {
> usleep(sleep_worker);
> printf("GLOB=%d\n", GLOB);
> return NULL;
> }
> int main(int argc, char **argv)
> {
> pthread_t threadid;
> pthread_create(&threadid, NULL, worker, NULL);
> usleep(sleep_parent);
> GLOB = 1;
> pthread_join(threadid, NULL);
> }
>
> /*
> % g++ -g missed_race.cc -lpthread
> % for((i=1; i <= 10; i++)); do echo ---------- $i;
> ~/race/valgrind32orig/Inst/bin/valgrind -q --tool=helgrind ./a.out 2>&1 |
> grep -A 5 Possible; done
> ---------- 1
> ---------- 2
> ---------- 3
> ---------- 4
> ---------- 5
> ---------- 6
> ==13246== Possible data race during write of size 4 at 0x8049850
> ==13246== at 0x8048585: main (missed_race.cc:40)
> ==13246== Old state: owned exclusively by thread #2
> ==13246== New state: shared-modified by threads #1, #2
> ==13246== Reason: this thread, #1, holds no locks at all
> GLOB=0
> ---------- 7
> ---------- 8
> ==13254== Possible data race during write of size 4 at 0x8049850
> ==13254== at 0x8048585: main (missed_race.cc:40)
> ==13254== Old state: owned exclusively by thread #2
> ==13254== New state: shared-modified by threads #1, #2
> ==13254== Reason: this thread, #1, holds no locks at all
> GLOB=0
> ---------- 9
> ---------- 10
> %
> */
>
>
|
|
From: Konstantin S. <kon...@gm...> - 2007-12-13 07:44:27
|
Hi,
The same false positive appears when mixing mutexes and semaphores. Test
attached.
As with cond vars, we are able to transition Excl(T1)->Excl(T2), but can not
do ShM(T1,T2)->Excl(T2).
As I understand, fixing this properly will require storing SegmentID in all
shadow words, not only in those that are in Exclusive state.
This will hardly squeeze into 32 bits though, need 64... :(
--kcc
#include <pthread.h>
#include <semaphore.h>
#include <unistd.h>
#include <stdio.h>
// This test is race free, but helgrind 3.3.0 reports a race
// main().........................worker()
// 1. start(worker)
// 2. lock(MU)
// 3. write(GLOB)
// 4. unlock(MU)
// a. lock(MU)
// b. write(GLOB)
// c. unlock(MU)
// 5. post(SEM)--------\
// \------> d. wait(SEM)
// e. write(GLOB)
// 6. join(worker)
// 7. read(GLOB)
int GLOB = 0;
sem_t SEM;
pthread_mutex_t MU = PTHREAD_MUTEX_INITIALIZER;
void *worker(void *) {
pthread_mutex_lock(&MU);
GLOB = 22;
pthread_mutex_unlock(&MU);
sem_wait(&SEM);
GLOB = 2; // RACE is reported here, but shouldn't
return NULL;
}
int main() {
sem_init(&SEM, 0, 0);
pthread_t thread;
pthread_create(&thread, NULL, worker, NULL);
pthread_mutex_lock(&MU);
GLOB = 11;
pthread_mutex_unlock(&MU);
sem_post(&SEM);
pthread_join(thread, NULL);
printf("glob=%d\n", GLOB);
}
On Dec 7, 2007 1:30 PM, Konstantin Serebryany <
kon...@gm...> wrote:
> >> Last night's patch (happens-before-cvhack.patch) also makes this, q2.cc
> ,
> >> run without race warnings.
>
> Amazing! --happens-before=cvhack does help with this patch!
> From the comments it does look 'insanely inefficient', but it's better
> than nothing. :)
> I'll try other tests with cond vars.
>
>
> >> Are you referring to the VALGRIND_HG_POST_WAIT that is introduced
> >> at the bottom of page 31 of Arndt Muehlenfeld's PhD thesis, or some
> >> other thing?
> Can you give me a link to Arndt's PhD? I can't find it :(
>
> --kcc
>
>
>
>
> On Dec 7, 2007 12:44 PM, Julian Seward < js...@ac...> wrote:
>
> >
> > On Thursday 06 December 2007 09:53, Konstantin Serebryany wrote:
> >
> > > I've modified my test (attached, q2.cc), hope it will be helpful :)
> > > It now has N worker threads. If N >= 2 the race is reported even for
> > GLOB1.
> >
> > Last night's patch (happens-before-cvhack.patch ) also makes this, q2.cc
> > ,
> > run without race warnings.
> >
> >
> > > I did not find VALGRIND_HG_POST_WAIT anywhere in valgrind nor in the
> > net.
> > > Is it supposed to be used like this?
> > >
> > > #include "helgrind.h"
> > > ...
> > > pthread_mutex_lock(&MU);
> > > while (COND != n_tasks) {
> > > pthread_cond_wait(&CV, &MU);
> > > }
> > > VALGRIND_HG_POST_WAIT(&CV)
> > > pthread_mutex_unlock(&MU);
> >
> > What is the behaviour of VALGRIND_HG_POST_WAIT supposed to be?
> >
> > Are you referring to the VALGRIND_HG_POST_WAIT that is introduced
> > at the bottom of page 31 of Arndt Muehlenfeld's PhD thesis, or some
> > other thing?
> >
> > J
> >
>
>
|
|
From: Tom H. <th...@cy...> - 2007-12-13 07:39:52
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-13 03:10:04 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 8 stderr failures, 4 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 8 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Dec 13 03:18:39 2007 --- new.short Thu Dec 13 03:26:57 2007 *************** *** 8,10 **** ! == 355 tests, 8 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) --- 8,10 ---- ! == 355 tests, 8 stderr failures, 4 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) *************** *** 16,17 **** --- 16,19 ---- none/tests/mremap2 (stdout) + none/tests/pth_cvsimple (stdout) + none/tests/pth_detached (stdout) helgrind/tests/tc18_semabuse (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-13 06:40:28
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-13 03:15:02 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 == 321 tests, 62 stderr failures, 1 stdout failure, 28 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-13 05:39:58
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-13 03:05:08 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 == 355 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: <js...@ac...> - 2007-12-13 01:23:35
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-13 02:00:01 CET 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 == 288 tests, 27 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |