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: Bart V. A. <bva...@ac...> - 2010-07-05 17:00:17
|
On Mon, Jul 5, 2010 at 12:20 PM, Konstantin Serebryany <kon...@gm...> wrote: > > On Mon, Jul 5, 2010 at 2:13 PM, Bart Van Assche <bva...@ac...> wrote: > > On Mon, Jul 5, 2010 at 11:32 AM, Konstantin Serebryany > > <kon...@gm...> wrote: > >> > >> +da...@go... > >> Julian, Bart, > >> > >> I've prepared a (draft) message to libstdc++. > >> Please review it. You are welcome to edit it directly too. > >> http://code.google.com/p/data-race-test/wiki/AtomicReferenceCounting > > > > While I welcome such an initiative, I have a few comments: > > - Asking the libstdc++ maintainers to use ANNOTATE_HAPPENS_BEFORE() > > and ANNOTATE_HAPPENS_AFTER() is not an option as long as there exist > > three different implementations of these macros (one in > > ThreadSanitizer, one in Helgrind and one in DRD). > > Agree. Shall we do something with this? I see three possible approaches: (a) Create a new shared library that contains at least a function for atomically decrementing a reference counter and kindly ask all authors of libraries that use reference-counted objects to use that new library for manipulating reference counts. That way data-race detection tools can recognize reference counters and the ordering imposed by decrementing reference counters by intercepting a single function. (b) Ask all authors of libraries that use reference-counted objects to add and export a function that does nothing else than decrementing a reference count. Also agree with these authors about a naming scheme for such a function such that all such functions can be intercepted via a single wildcard pattern in Valgrind. (c) Ask library authors to insert a Valgrind client request before each reference counter decrement and after each reference counter decrement that set the reference count equal to zero. We should also consider wherever reference counts are decremented in inline functions in public header files, to make the above behavior configurable via preprocessor symbol. Certain behavior of libstdc++ is already configurable via preprocessor symbols, e.g. via the preprocessor symbol GLIBCXX_FORCE_NEW. We can either try to agree upon one of the above three approaches or ask the libstdc++ authors for their opinion. Note: as is documented in the header file <valgrind/valgrind.h>, the preprocessor symbol NVALGRIND controls whether or not Valgrind client requests are inserted in the output code. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2010-07-05 10:21:21
|
On Mon, Jul 5, 2010 at 2:13 PM, Bart Van Assche <bva...@ac...> wrote: > On Mon, Jul 5, 2010 at 11:32 AM, Konstantin Serebryany > <kon...@gm...> wrote: >> >> +da...@go... >> Julian, Bart, >> >> I've prepared a (draft) message to libstdc++. >> Please review it. You are welcome to edit it directly too. >> http://code.google.com/p/data-race-test/wiki/AtomicReferenceCounting > > While I welcome such an initiative, I have a few comments: > - Asking the libstdc++ maintainers to use ANNOTATE_HAPPENS_BEFORE() > and ANNOTATE_HAPPENS_AFTER() is not an option as long as there exist > three different implementations of these macros (one in > ThreadSanitizer, one in Helgrind and one in DRD). Agree. Shall we do something with this? > - Asking to implement a function __decrement_refcount() will only help > if this function is never inlined. Yes (and this is mentioned in the wiki). We are thinking about ways to avoid this restriction, but currently, yes, you are right. > That will cause a slight slowdown > of every reference counting implementation. I'm afraid that such a > request will not be accepted by the libstdc++ maintainers. > - A nitpick: are you sure that the following statement is correct: > "However, it is hard or impossible to interpret raw atomic > instructions as synchronization" ? There is explanation in the same phrase: (e.g. treating every compare-and-exchange instruction or every instruction with lock prefix as a synchronization event will make the analysis very slow and conservative). Perhaps you could write a more understandable sentence. :) --kcc > While - at least in DRD - it is > easy to associate ordering semantics with all atomic instructions, > doing so would cause many real races not to be reported. > > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2010-07-05 10:13:51
|
On Mon, Jul 5, 2010 at 11:32 AM, Konstantin Serebryany <kon...@gm...> wrote: > > +da...@go... > Julian, Bart, > > I've prepared a (draft) message to libstdc++. > Please review it. You are welcome to edit it directly too. > http://code.google.com/p/data-race-test/wiki/AtomicReferenceCounting While I welcome such an initiative, I have a few comments: - Asking the libstdc++ maintainers to use ANNOTATE_HAPPENS_BEFORE() and ANNOTATE_HAPPENS_AFTER() is not an option as long as there exist three different implementations of these macros (one in ThreadSanitizer, one in Helgrind and one in DRD). - Asking to implement a function __decrement_refcount() will only help if this function is never inlined. That will cause a slight slowdown of every reference counting implementation. I'm afraid that such a request will not be accepted by the libstdc++ maintainers. - A nitpick: are you sure that the following statement is correct: "However, it is hard or impossible to interpret raw atomic instructions as synchronization" ? While - at least in DRD - it is easy to associate ordering semantics with all atomic instructions, doing so would cause many real races not to be reported. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2010-07-05 09:32:55
|
+da...@go... Julian, Bart, I've prepared a (draft) message to libstdc++. Please review it. You are welcome to edit it directly too. http://code.google.com/p/data-race-test/wiki/AtomicReferenceCounting --kcc On Fri, Jul 2, 2010 at 9:10 PM, Konstantin Serebryany <kon...@gm...> wrote: > On Fri, Jul 2, 2010 at 2:19 PM, Bart Van Assche <bva...@ac...> wrote: >> On Fri, Jul 2, 2010 at 9:03 AM, Julian Seward <js...@ac...> wrote: >>> >>> > I don't think we need to use ANNOTATE_* in standard libraries. >>> > Instead, I want to ask the library writers to arrange their code to >>> > make it easier to intercept by valgrind tools. >>> > In particular, for atomic ref counting I want to ask them to have a new >>> > function which simply means "atomically decrement reference count and >>> > return whether count is zero". That function could itself simply call >>> > __exchange_and_add_dispatch or whatever. >>> >>> Yes. Perhaps "T atomic_decrement(T*)", for some T (unsigned int etc) >>> and returns the new T. Synthesising "is new count == 0" into a 32/64-bit >>> value is expensive -- requires "testl ; set ; movzbl" -- better simply >>> to return the new value, which we have for free on LL/SC based platforms >>> (ARM, PPC) anyway, and also on x86/x86_64 if the atomic dec is encoded >>> using "load, sub, cmpxchg, check-the-cmpxchg succeeded". >>> >>> Why not just use the gcc builtin naming scheme for atomic operations? >>> It's uniform across multiple archs, and makes it clear whether the >>> returned value is the value before or after the decrement. No need to >>> reinvent the wheel. >> >> Only instrumenting the atomic decrement is not sufficient IMHO. The >> atomic increment has to be instrumented too, such that it is possible >> for a data race detection tool to find out which happens-before arcs >> to insert. > > Instrumenting ref count decrement was never needed in my practice. > In my practice we needed to instrument a function RefCountIsOne() in > addition to RefCountIncrement(); > > bool RefCountIsOne() { > bool res = AtomicRead(&ref_count_) == 1; > if (res) { > ANNOTATE_HAPPENS_AFTER(&ref_count_); > } > return res; > } > ... > if (x.RefCountIsOne()) { > x.DoSomethingWithXWithoutLocksBecauseWeOwnXAndAreGoingToDeleteIt. > } > > >> >>> --------------- >>> >>> Kind-of related comment: >>> >>> One observation w.r.t. refcounting and C++ is, when the refcount makes >>> a 1 -> 0 transition then the object becomes exclusively owned by the >>> decrementing thread, and so it can run its destructor without any >>> locking. However, at least Helgrind does not understand that, and so >>> needs to be told the object is now exclusively owned by the calling >>> thread before running the destructor. >>> >>> In this case, the obvious thing to do seems like >>> >>> VALGRIND_HG_CLEAN_MEMORY(this, sizeof(*this)) >>> >>> but this is wrong in the presence of inheritance, when a class defines a >>> ::Release method, and is then subclassed, but the subclass doesn't provide >>> its own ::Release. Then "sizeof(*this)" will be too small, because it is >>> the size of the base class, not the runtime size. Also, in the presence of >>> multiple inheritance, there is no guarantee that "this" points to the >>> start of the object; we are only assured that it points either to the >>> start or somewhere within it. >>> >>> For this reason I recently added to Helgrind a new clreq, >>> VALGRIND_HG_CLEAN_MEMORY_HEAPBLOCK(ptr), which is the same as >>> VALGRIND_HG_CLEAN_MEMORY applied to whatever heap block "ptr" points >>> into, if any, and it's OK if it's an interior pointer. >>> >>> Do TSan and DRD have anything similar? >>> >>> This isn't theoretical. I found it out the hard way when analysing >>> an ocean of false race reports when Helgrinding C++ code using atomic >>> refcounting and inheritance, earlier this year. >> >> This kind of issue can indeed arise when letting the client program >> communicate to the tool how many bytes will be freed. But why to >> invoke such a client request from the client code while the tool >> already has exact information about the number of bytes that will be >> freed ? I'm assuming here that each reference counted object is >> allocated via an individual memory request, and that no memory region >> contains two or more reference-counted objects that are freed >> individually. > > See my previous message. The deleted object could be a compound > structure, not just a sequence of bytes. > The is not the case for std::string, but could be easily the case for > some other C++ stuff from e.g. boost. > We have tons of such classes, but they all use a single ref-counting > utility annotated with HAPPENS_BEFORE/AFTER and so they are > race-detector friendly. > > > --kcc > >> >> Bart. >> > |
|
From: <sv...@va...> - 2010-07-05 07:21:33
|
Author: njn
Date: 2010-07-05 08:21:22 +0100 (Mon, 05 Jul 2010)
New Revision: 11208
Log:
Convert x86-darwin to amd64-darwin at configure time, because Macs report as
32-bit even though almost all of them support 64-bit as well. A hack, but
one that will make just about everyone's lives easier.
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2010-07-02 19:56:23 UTC (rev 11207)
+++ trunk/configure.in 2010-07-05 07:21:22 UTC (rev 11208)
@@ -291,7 +291,7 @@
*)
AC_MSG_RESULT([no (${host_os})])
- AC_MSG_ERROR([Valgrind is operating system specific. Sorry. Please consider doing a port.])
+ AC_MSG_ERROR([Valgrind is operating system specific. Sorry.])
;;
esac
@@ -473,20 +473,15 @@
fi
AC_MSG_RESULT([ok (${ARCH_MAX}-${VGCONF_OS})])
;;
- x86-darwin)
- VGCONF_ARCH_PRI="x86"
- VGCONF_ARCH_SEC=""
- VGCONF_PLATFORM_PRI_CAPS="X86_DARWIN"
- VGCONF_PLATFORM_SEC_CAPS=""
- valt_load_address_pri_norml="0x38000000"
- valt_load_address_pri_inner="0x28000000"
+ # Darwin gets identified as 32-bit even when it supports 64-bit.
+ # (Not sure why, possibly because 'uname' returns "i386"?) Just about
+ # all Macs support both 32-bit and 64-bit, so we just build both. If
+ # someone has a really old 32-bit only machine they can (hopefully?)
+ # build with --enable-only32bit. See bug 243362.
+ x86-darwin|amd64-darwin)
+ ARCH_MAX="amd64"
valt_load_address_sec_norml="0xUNSET"
valt_load_address_sec_inner="0xUNSET"
- AC_MSG_RESULT([ok (${ARCH_MAX}-${VGCONF_OS})])
- ;;
- amd64-darwin)
- valt_load_address_sec_norml="0xUNSET"
- valt_load_address_sec_inner="0xUNSET"
if test x$vg_cv_only64bit = xyes; then
VGCONF_ARCH_PRI="amd64"
VGCONF_ARCH_SEC=""
|