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
(25) |
2
(13) |
3
(3) |
|
4
|
5
(5) |
6
(12) |
7
(5) |
8
(16) |
9
(3) |
10
|
|
11
|
12
|
13
(4) |
14
(1) |
15
(2) |
16
(6) |
17
|
|
18
|
19
(1) |
20
(2) |
21
(10) |
22
(9) |
23
(8) |
24
(5) |
|
25
|
26
(6) |
27
(8) |
28
(8) |
29
(23) |
30
(12) |
31
(6) |
|
From: Dave G. <go...@mc...> - 2010-07-07 22:20:58
|
I have some multithreaded code that signals object "completion" with a flag variable. Initially the flag value is non-zero (almost always 1) and one thread (A) will do some work to determine the values for various fields in the object. When thread A is finished with the object, it indicates that the object is complete by setting the flag to zero. This is a one-way transition, the object will be read exclusively by the (guaranteed) single consumer thread (B) and eventually destroyed by thread B.
I have inserted memory barriers in both the producer's and consumer's code to provide store-release/load-acquire semantics with the flag variable. Well, in the example code at the bottom, I used full barriers, but I think that acquire/release is really all I need.
These reads and writes are of course flagged by the various valgrind threading tools (helgrind/drd/tsan) as potential races. However I was surprised to find that I could not successfully annotate this sort of behavior in the same way as I would an atomic reference counting scheme. At the bottom of this mail is some example code that illustrates my scenario. The read itself is flagged as racy before the HAPPENS_AFTER annotation. In DRD and TSan, I can at least ANNOTATE_BENIGN_RACE as a last resort, but Helgrind doesn't support this annotation.
Changing the unconditional write in the producer thread to an atomic decrement makes the annotations work again, as in refcounting. This may be what I use in the end to solve this problem, but I do still want to understand why I can't annotate it correctly.
Q1: I know it's potentially error prone in terms of usage and implementation, but I'm attempting something that is basically sane, right?
Q2: Is there a way to correctly annotate the store/load pair, ideally across all three tools? Or for helgrind am I stuck with suppressions?
Thanks,
-Dave
------8<------
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <unistd.h>
#include <pthread.h>
/* change this to change tool annotations */
#define USE_HELGRIND
/* don't define this to get atomic_fetch_and_decr */
#define USE_PLAIN_STORE
#if defined(USE_HELGRIND)
#include <valgrind/helgrind.h>
#elif defined(USE_DRD)
#include <valgrind/drd.h>
#elif defined(USE_TSAN)
#include <dynamic_annotations.h>
#endif
volatile int flag = 1;
int shared_data;
void *completer(void *context)
{
sleep(5); /* do some "work" */
/* this thread exclusively owns shared_data */
shared_data = 0xdeadbeef;
/* now indicate the shared_data is complete and owned by the other thread */
__sync_synchronize(); /* full memory barrier */
ANNOTATE_HAPPENS_BEFORE(&flag);
#if defined(USE_PLAIN_STORE)
flag = 0;
#else
__sync_sub_and_fetch(&flag, 1);
#endif
return NULL;
}
int main(int argc, char **argv)
{
int err;
pthread_t other_thread;
err = pthread_create(&other_thread, NULL, completer, NULL);
assert(!err);
while (1) {
if (0 == flag) {
ANNOTATE_HAPPENS_AFTER(&flag);
__sync_synchronize(); /* full memory barrier */
break;
}
}
/* this thread now owns the shared data and can access it freely */
printf("shared_data=%#x\n", shared_data);
pthread_join(other_thread, NULL);
return 0;
}
------8<------
And here's the output from Helgrind:
------8<------
% valgrind --tool=helgrind --read-var-info=yes -q ./a.out
==27470== Thread #2 was created
==27470== at 0x511EB0E: clone (in /lib/libc-2.7.so)
==27470== by 0x4E31A11: pthread_create@@GLIBC_2.2.5 (in /lib/libpthread-2.7.so)
==27470== by 0x4C286AA: pthread_create_WRK /sandbox/goodell/drt/third_party/valgrind/helgrind/hg_intercepts.c:257
==27470== by 0x4C287AA: pthread_create@* /sandbox/goodell/drt/third_party/valgrind/helgrind/hg_intercepts.c:288
==27470== by 0x40099B: main /sandbox/goodell/scratch/flag-hb/foo.c:45
==27470==
==27470== Thread #1 is the program's root thread
==27470==
==27470== Possible data race during write of size 4 at 0x600f08 by thread #2
==27470== at 0x400964: completer /sandbox/goodell/scratch/flag-hb/foo.c:34
==27470== by 0x4C2882D: mythread_wrapper /sandbox/goodell/drt/third_party/valgrind/helgrind/hg_intercepts.c:221
==27470== by 0x4E313F6: start_thread (in /lib/libpthread-2.7.so)
==27470== by 0x511EB4C: clone (in /lib/libc-2.7.so)
==27470== This conflicts with a previous read of size 4 by thread #1
==27470== at 0x4009BE: main /sandbox/goodell/scratch/flag-hb/foo.c:49
==27470== Location 0x600f08 is 0 bytes inside global var "flag"
==27470== declared at foo.c:20
==27470==
==27470== Possible data race during read of size 4 at 0x600f08 by thread #1
==27470== at 0x4009BE: main /sandbox/goodell/scratch/flag-hb/foo.c:49
==27470== This conflicts with a previous write of size 4 by thread #2
==27470== at 0x400964: completer /sandbox/goodell/scratch/flag-hb/foo.c:34
==27470== by 0x4C2882D: mythread_wrapper /sandbox/goodell/drt/third_party/valgrind/helgrind/hg_intercepts.c:221
==27470== by 0x4E313F6: start_thread (in /lib/libpthread-2.7.so)
==27470== by 0x511EB4C: clone (in /lib/libc-2.7.so)
==27470== Location 0x600f08 is 0 bytes inside global var "flag"
==27470== declared at foo.c:20
==27470==
shared_data=0xdeadbeef
------8<------
|
|
From: <sv...@va...> - 2010-07-07 19:01:46
|
Author: weidendo
Date: 2010-07-07 19:51:59 +0100 (Wed, 07 Jul 2010)
New Revision: 11212
Log:
Fix for branch prediction: handle calls via function pointer
Calls via function pointers are indirect branches, and thus
should call into the indirect branch predictor simulation.
Modified:
trunk/callgrind/main.c
Modified: trunk/callgrind/main.c
===================================================================
--- trunk/callgrind/main.c 2010-07-06 04:25:12 UTC (rev 11211)
+++ trunk/callgrind/main.c 2010-07-07 18:51:59 UTC (rev 11212)
@@ -1180,7 +1180,7 @@
/* Deal with branches to unknown destinations. Except ignore ones
which are function returns as we assume the return stack
predictor never mispredicts. */
- if (sbIn->jumpkind == Ijk_Boring) {
+ if ((sbIn->jumpkind == Ijk_Boring) || (sbIn->jumpkind == Ijk_Call)) {
if (0) { ppIRExpr( sbIn->next ); VG_(printf)("\n"); }
switch (sbIn->next->tag) {
case Iex_Const:
|
|
From: Rich C. <rc...@wi...> - 2010-07-07 04:17:36
|
Nightly build on macbook ( Darwin 9.8.0 i386 ) Started at 2010-07-06 23:05:00 CDT Ended at 2010-07-06 23:17:27 CDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... failed Last 20 lines of verbose log follow echo Making check in . make addressable atomic_incs badaddrvalue badfree badjump badjump2 badloop badpoll badrw brk2 buflen_check calloc-overflow clientperm custom_alloc custom-overlap deep_templates describe-block doublefree error_counts errs1 exitprog execve execve2 erringfds file_locking fprw fwrite inits inline leak-0 leak-cases leak-cycle leak-pool leak-tree linux-syslog-syscall linux-syscalls-2007 long_namespace_xml long-supps mallinfo malloc_free_fill malloc_usable malloc1 malloc2 malloc3 manuel1 manuel2 manuel3 match-overrun memalign_test memalign2 memcmptest mempool mmaptest mismatches new_override metadata nanoleak_supp nanoleak2 new_nothrow noisy_child null_socket origin1-yes origin2-not-quite origin3-no origin4-many origin5-bz2 origin6-fp overlap partiallydefinedeq partial_load pdb-realloc pdb-realloc2 pipe pointer-trace post-syscall realloc1 realloc2 realloc3 sh-mem sh-mem-random sigaltstack signal2 sigprocmask sigkill strchr str_tester supp_unknown supp1 supp2 suppfree trivialleak un it_libcbase unit_oset varinfo1 varinfo2 varinfo3 varinfo4 varinfo5 varinfo5so.so varinfo6 vcpu_fbench vcpu_fnfns xml1 wrap1 wrap2 wrap3 wrap4 wrap5 wrap6 wrap7 wrap7so.so wrap8 writev gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1 -Winline -Wall -Wshadow -g -arch x86_64 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT addressable.o -MD -MP -MF .deps/addressable.Tpo -c -o addressable.o addressable.c mv -f .deps/addressable.Tpo .deps/addressable.Po gcc -Winline -Wall -Wshadow -g -arch x86_64 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -o addressable addressable.o gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -DVGA_amd64=1 -DVGO_darwin=1 -DVGP_amd64_darwin=1 -Winline -Wall -Wshadow -g -arch x86_64 -mdynamic-no-pic -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT atomic_incs-atomic_incs.o -MD -MP -MF .deps/atomic_incs-atomic_incs.Tpo -c -o atomic_incs-atomic_incs.o `test -f 'atomic_incs.c' || echo './'`atomic_incs.c atomic_incs.c: In function 'atomic_add_8bit': atomic_incs.c:37: error: PIC register 'rbx' clobbered in 'asm' atomic_incs.c: In function 'atomic_add_16bit': atomic_incs.c:101: error: PIC register 'rbx' clobbered in 'asm' atomic_incs.c: In function 'atomic_add_32bit': atomic_incs.c:164: error: PIC register 'rbx' clobbered in 'asm' atomic_incs.c: In function 'atomic_add_64bit': atomic_incs.c:219: error: PIC register 'rbx' clobbered in 'asm' make[5]: *** [atomic_incs-atomic_incs.o] Error 1 make[4]: *** [check-am] Error 2 make[3]: *** [check-recursive] Error 1 make[2]: *** [check-recursive] Error 1 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 Congratulations, all tests passed! |
|
From: Tom H. <th...@cy...> - 2010-07-07 02:46:12
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2010-07-07 03:05:03 BST Ended at 2010-07-07 03:45:58 BST 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 == 546 tests, 2 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2010-07-07 02:37:16
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2010-07-07 03:10:06 BST Ended at 2010-07-07 03:36:59 BST 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 == 553 tests, 2 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) helgrind/tests/tc06_two_races_xml (stderr) |