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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(6) |
2
(7) |
|
3
(12) |
4
(9) |
5
(12) |
6
(9) |
7
(18) |
8
(10) |
9
(17) |
|
10
(15) |
11
(22) |
12
(16) |
13
(18) |
14
(9) |
15
(14) |
16
(18) |
|
17
(24) |
18
(11) |
19
(15) |
20
(29) |
21
(19) |
22
(20) |
23
(9) |
|
24
(25) |
25
(25) |
26
(38) |
27
(22) |
28
(16) |
29
(17) |
|
|
From: Tom H. <th...@cy...> - 2008-02-23 03:27:29
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-02-23 03:10:05 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 == 372 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) |
|
From: Tom H. <th...@cy...> - 2008-02-23 03:14:30
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-02-23 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 == 378 tests, 29 stderr failures, 3 stdout failures, 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/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) 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: Josef W. <Jos...@gm...> - 2008-02-22 18:26:57
|
On Friday 22 February 2008, Konstantin Serebryany wrote: > Hi, > > A question similar to the one discussed in 'thread-change callback' thread. > How can I see context change events (i.e. when some thread enters or > exits a function)? Possibilities: * At instrumentation time, check if a given instruction is the first of a function according to debug information. This way, you get "enter function" events, but not "exit" events. Instrumenting also every exit can get complex, and you probably end with something similar to part of Callgrinds functionality. * Extract the according functionality from Callgrind into a core module to make it usable by every tool. There is a shadow callstack which is resynchronized with the real one, making this approach quite robust. E.g. it works with recursion, longjmps etc. Drawback aside from not-existing module: slowdown because of an instrumented callback at beginning of every basic block (could be optimized to do the callback at end of BBs instead at beginning, and only when changing the context). * For specific functions, functions wrappers can be installed. This redirects jumps to the given function to another one you provide in a shared lib which will be loaded by valgrind dependent on the tool. Function exits work this way, as the wrapper has its stack frame on the client stack. Callbacks into your tool have to be done via client requests from the wrapper. AFAIK, this has problems with recursion and longjmps. In general, as VG is running machine code, and you probably define "context change" as C/C++/... function changes, there is not always an exact relation among them, and thus sometimes difficult whether a given execution should really trigger a context change or not (e.g. with end recursion optimization). Josef |
|
From: Bart V. A. <bar...@gm...> - 2008-02-22 17:53:12
|
On Fri, Feb 22, 2008 at 3:57 PM, Julian Seward <js...@ac...> wrote: > track_start/stop_client_code does only show you when the CPU is > running translated code blocks. However, it may be that a thread > has the CPU but is not running translated code, but instead doing > one of many other things (including building signal frames). > That's the difference: get_running_tid shows you what thread has > the CPU. In exp-drd I need the value of VG_(get_running_tid)() upon *every* client memory access, not just for the memory accesses generated by translated code. I would appreciate it very much that the Valgrind core would announce changes in VG_(get_running_tid)() instead of having to verify the value of VG_(get_running_tid)() in the tool. > Are you intercepting both track_start_client_code and track_stop_client_code, > or only the _start ? Only _start. Even if I would track _stop, I still would need code in the drd_trace_load() / drd_trace_store() functions for verifying whether VG_(get_running_tid)() changed. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2008-02-22 15:44:46
|
Hi, A question similar to the one discussed in 'thread-change callback' thread. How can I see context change events (i.e. when some thread enters or exits a function)? Thanks, --kcc |
|
From: Julian S. <js...@ac...> - 2008-02-22 14:40:55
|
On Friday 22 February 2008 15:24, Bart Van Assche wrote:
> On Fri, Feb 22, 2008 at 2:38 PM, Julian Seward <js...@ac...> wrote:
> > I am (very) surprised to hear that track_{start,stop}_client_code
> > give wrong results.
>
> As soon as I have the time I will look further into this issue. But
> please note that I have raised this issue more than once in the past
> -- see e.g. http://bugs.kde.org/show_bug.cgi?id=152728.
Yes. I'm only saying that track_{start,stop}_client_code look correct
to me, and so the problem is more likely to be elsewhere, perhaps:
VG_(get_running_tid)() produces wrong results, under some circumstances,
or
the assertion that VG_(get_running_tid)() and track_{start,stop}_client_code
agree is not always valid, for some subtle reason.
I am a bit unclear about the precise semantics of VG_(get_running_tid)
(was it ever specified, exactly? I don't know). That probably doesn't
help. A first step might be to specify exactly the behaviour of this fn.
J
|
|
From: Josef W. <Jos...@gm...> - 2008-02-22 14:39:56
|
On Friday 22 February 2008, Julian Seward wrote:
> > > > trace_start_client_code
> > > > track_stop_client_code
> ...
> > > The above is not sufficient.
> ...
> I am (very) surprised to hear that track_{start,stop}_client_code
> give wrong results. The reason is that (translations of) client code
> (and I mean *all* client code, including client signal handlers)
<OT>
"Signal handler exit via longjmp" is offtopic here, but how should valgrind
core be able to detect this, as the signal frame is silently discarded by
longjmp? This is also clearly stated in "pub_tool_tooliface.h":
/* Called after a signal is delivered. Nb: unfortunately, if the signal
handler longjmps, this won't be called. */
void VG_(track_post_deliver_signal)(void(*f)(ThreadId tid, Int sigNo));
However, this is not important for Callgrind as with the regular resync.
of the shadow stack against the real one, this case still is catched
without any help from VG core.
</OT>
> So perhaps tid is wrong here?
For Callgrind, it is a non-issue, as setup_bbcc is called at beginning
of every BB. So I wanted to play safe and did the adjustment against
VG_(get_running_tid) there. I could skip this and make an assertion instead.
Josef
|
|
From: Bart V. A. <bar...@gm...> - 2008-02-22 14:24:22
|
On Fri, Feb 22, 2008 at 2:38 PM, Julian Seward <js...@ac...> wrote:
> I am (very) surprised to hear that track_{start,stop}_client_code
> give wrong results.
As soon as I have the time I will look further into this issue. But
please note that I have raised this issue more than once in the past
-- see e.g. http://bugs.kde.org/show_bug.cgi?id=152728.
Bart.
|
|
From: Julian S. <js...@ac...> - 2008-02-22 13:46:38
|
> > > trace_start_client_code
> > > track_stop_client_code
> > >
> > > Are any of these good enough? (I really thought we had a
> > > track_thread_switch event...)
> >
> > The above is not sufficient. I have tried in exp-drd to only update
> > the cached thread ID when one of the above events was generated. The
> > result was that for several test cases the cached thread ID was not
> > equal to VG_(get_running_tid()). An example of such a test case is
> > exp-drd/tests/sigalrm.c.
>
> Did you research the reason for this?
Yes, that is a good question.
I am (very) surprised to hear that track_{start,stop}_client_code
give wrong results. The reason is that (translations of) client code
(and I mean *all* client code, including client signal handlers)
can only be reached through the following functions
coregrind/m_scheduler/scheduler.c: run_thread_for_a_while
coregrind/m_scheduler/scheduler.c: run_noredir_translation
There is no other way for a translation to be run.
In both functions, the call to the generated code is bracketed
by these:
// Tell the tool this thread is about to run client code
VG_TRACK( start_client_code, tid, bbs_done );
// Tell the tool this thread has stopped running client code
VG_TRACK( stop_client_code, tid, bbs_done );
So perhaps tid is wrong here? But it can't be: the tid
passed to run_thread_for_a_while and run_noredir_translation
is used to select which set of guest registers to use for the
run, and so if it was wrong threaded programs as a whole would
die in a very obvious way.
J
|
|
From: Josef W. <Jos...@gm...> - 2008-02-22 12:35:30
|
Hi, On Friday 22 February 2008, Bart Van Assche wrote: > > > This would be useful for exp-drd too. What I do now is to compare the > > > result of VG_(get_running_tid)() with a cached value in order to > > > detect when Valgrind scheduled another thread. This test is performed > > > upon every load, every store, and every time the stack pointer is > > > modified. > > > > I thought we had such an event -- I thought Josef used it in Callgrind. > > In include/pub_tool_tooliface.h I see: > > > > track_start_client_code Actually, I use this one. But I do not fully rely on it. Callgrind has the "nice" property that it instruments a callback at begin of every basic block. And there, I adjust to VG_(get_running_tid)(). In Callgrind, I have the additional requirement the reliable track enter/leave of signal handlers. This is not possible with the hooks provided by valgrind, e.g. in the case of a longjmp from signal handler into regular code. > > track_stop_client_code > > track_pre_thread_ll_create > > track_pre_thread_ll_create > > track_pre_thread_ll_exit > > > > Are any of these good enough? (I really thought we had a > > track_thread_switch event...) > > The above is not sufficient. I have tried in exp-drd to only update > the cached thread ID when one of the above events was generated. The > result was that for several test cases the cached thread ID was not > equal to VG_(get_running_tid()). An example of such a test case is > exp-drd/tests/sigalrm.c. Did you research the reason for this? I have this quite old comment before my "TID adjustment" (bbcc.c:536): /* This is needed because thread switches can not reliable be tracked * with callback CLG_(run_thread) only: we have otherwise no way to get * the thread ID after a signal handler returns. * This could be removed again if that bug is fixed in Valgrind. * This is in the hot path but hopefully not to costly. */ Josef |
|
From: Bart V. A. <bar...@gm...> - 2008-02-22 07:24:45
|
On Thu, Feb 21, 2008 at 10:16 PM, Nicholas Nethercote <nj...@cs...> wrote: > On Thu, 21 Feb 2008, Bart Van Assche wrote: > > >> One of the things I have come to realise in the past year or so > >> is what a terrible programming model explicit shared-memory parallelism > >> is. It's simply too hard for humans to understand and reason about > >> (in all but the most trivial of applications): even small threaded > >> programs are extremely hard to make sense of. > > > > It depends. Although understanding concurrent activities is always > > hard, it is possible to write multithreaded software that is > > relatively easy to read and to maintain. What I have learned during > > the past ten years about writing multithreaded software is a.o. the > > following: > > So basically you need various higher-level abstractions layered over > pthreads, plus a strong dose of programmer discipline. So it's doable, but > hoping everyone will get it right is optimistic. My opinion is that software developers should do a serious effort at preventing problems and that they should not just rely on error detection tools. The same holds for memory leaks / dangling pointers: in large applications it is important that there is a clear strategy with regard to ownership of dynamically allocated memory. Sophisticated memory checking and leak checking tools do not provide a solution in case there is no clear ownership policy in the software being checked. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2008-02-22 07:15:24
|
On Thu, Feb 21, 2008 at 10:19 PM, Nicholas Nethercote <nj...@cs...> wrote: > On Thu, 21 Feb 2008, Bart Van Assche wrote: > > On Thu, Feb 21, 2008 at 6:38 PM, Vince Weaver <vi...@cs...> wrote: > > > To do this properly, it would be nice if it were possible to be notified > > > whenever a thread-change happened. That way the statistics from the > > > various threads could be kept separately. > > > > This would be useful for exp-drd too. What I do now is to compare the > > result of VG_(get_running_tid)() with a cached value in order to > > detect when Valgrind scheduled another thread. This test is performed > > upon every load, every store, and every time the stack pointer is > > modified. > > I thought we had such an event -- I thought Josef used it in Callgrind. > In include/pub_tool_tooliface.h I see: > > track_start_client_code > track_stop_client_code > track_pre_thread_ll_create > track_pre_thread_ll_create > track_pre_thread_ll_exit > > Are any of these good enough? (I really thought we had a > track_thread_switch event...) The above is not sufficient. I have tried in exp-drd to only update the cached thread ID when one of the above events was generated. The result was that for several test cases the cached thread ID was not equal to VG_(get_running_tid()). An example of such a test case is exp-drd/tests/sigalrm.c. Bart. |
|
From: Tom H. <th...@cy...> - 2008-02-22 05:05:10
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-02-22 03:15:06 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 == 338 tests, 80 stderr failures, 1 stdout failure, 29 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/lsframe1 (stderr) memcheck/tests/lsframe2 (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-names (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/blockfault (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/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) exp-drd/tests/fp_race (stderr) exp-drd/tests/fp_race2 (stderr) exp-drd/tests/matinv (stderr) exp-drd/tests/pth_barrier (stderr) exp-drd/tests/pth_broadcast (stderr) exp-drd/tests/pth_cond_race (stderr) exp-drd/tests/pth_cond_race2 (stderr) exp-drd/tests/pth_create_chain (stderr) exp-drd/tests/pth_detached (stderr) exp-drd/tests/pth_detached2 (stderr) exp-drd/tests/sem_as_mutex (stderr) exp-drd/tests/sem_as_mutex2 (stderr) exp-drd/tests/sigalrm (stderr) exp-drd/tests/tc17_sembar (stderr) exp-drd/tests/tc18_semabuse (stderr) |
|
From: Tom H. <th...@cy...> - 2008-02-22 04:04:37
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-02-22 03:05:07 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 == 372 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: Tom H. <th...@cy...> - 2008-02-22 03:52:53
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-02-22 03:25:26 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 == 376 tests, 6 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-02-22 03:46:45
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-02-22 03:20:06 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 == 378 tests, 8 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-02-22 03:27:30
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-02-22 03:10:06 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 == 372 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) |
|
From: Tom H. <th...@cy...> - 2008-02-22 03:14:41
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-02-22 03:00:03 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 == 378 tests, 29 stderr failures, 3 stdout failures, 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/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) 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: <sv...@va...> - 2008-02-22 01:19:50
|
Author: sewardj
Date: 2008-02-22 01:19:49 +0000 (Fri, 22 Feb 2008)
New Revision: 7434
Log:
Connect Helgrind up to the new address-describing machinery.
Modified:
branches/DATASYMS/coregrind/m_debuginfo/debuginfo.c
branches/DATASYMS/helgrind/hg_main.c
Modified: branches/DATASYMS/coregrind/m_debuginfo/debuginfo.c
===================================================================
--- branches/DATASYMS/coregrind/m_debuginfo/debuginfo.c 2008-02-21 20:32:57 UTC (rev 7433)
+++ branches/DATASYMS/coregrind/m_debuginfo/debuginfo.c 2008-02-22 01:19:49 UTC (rev 7434)
@@ -1678,12 +1678,12 @@
if ( frameNo >= 0 && (!have_srcloc) && (!have_descr) ) {
/* no srcloc, no description:
- Address 0x7fefff6cf is 543 bytes inside local var "a",
+ Location 0x7fefff6cf is 543 bytes inside local var "a",
in frame #1 of thread 1
*/
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside local var \"%s\",",
+ "Location 0x%lx is %lu byte%s inside local var \"%s\",",
data_addr, var_offset, vo_plural, var->name );
VG_(snprintf)(
dname2, n_dname,
@@ -1692,12 +1692,12 @@
else
if ( frameNo >= 0 && have_srcloc && (!have_descr) ) {
/* no description:
- Address 0x7fefff6cf is 543 bytes inside local var "a"
+ Location 0x7fefff6cf is 543 bytes inside local var "a"
declared at dsyms7.c:17, in frame #1 of thread 1
*/
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside local var \"%s\"",
+ "Location 0x%lx is %lu byte%s inside local var \"%s\"",
data_addr, var_offset, vo_plural, var->name );
VG_(snprintf)(
dname2, n_dname,
@@ -1707,12 +1707,12 @@
else
if ( frameNo >= 0 && (!have_srcloc) && have_descr ) {
/* no srcloc:
- Address 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2
+ Location 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2
in frame #1 of thread 1
*/
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside %s%s",
+ "Location 0x%lx is %lu byte%s inside %s%s",
data_addr, residual_offset, ro_plural, var->name,
VG_(indexXA)(described,0) );
VG_(snprintf)(
@@ -1721,11 +1721,11 @@
}
else
if ( frameNo >= 0 && have_srcloc && have_descr ) {
- /* Address 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2,
+ /* Location 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2,
declared at dsyms7.c:17, in frame #1 of thread 1 */
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside %s%s,",
+ "Location 0x%lx is %lu byte%s inside %s%s,",
data_addr, residual_offset, ro_plural, var->name,
VG_(indexXA)(described,0) );
VG_(snprintf)(
@@ -1737,22 +1737,22 @@
/* ------ global cases ------ */
if ( frameNo >= -1 && (!have_srcloc) && (!have_descr) ) {
/* no srcloc, no description:
- Address 0x7fefff6cf is 543 bytes inside global var "a"
+ Location 0x7fefff6cf is 543 bytes inside global var "a"
*/
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside global var \"%s\"",
+ "Location 0x%lx is %lu byte%s inside global var \"%s\"",
data_addr, var_offset, vo_plural, var->name );
}
else
if ( frameNo >= -1 && have_srcloc && (!have_descr) ) {
/* no description:
- Address 0x7fefff6cf is 543 bytes inside global var "a"
+ Location 0x7fefff6cf is 543 bytes inside global var "a"
declared at dsyms7.c:17
*/
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside global var \"%s\"",
+ "Location 0x%lx is %lu byte%s inside global var \"%s\"",
data_addr, var_offset, vo_plural, var->name );
VG_(snprintf)(
dname2, n_dname,
@@ -1762,12 +1762,12 @@
else
if ( frameNo >= -1 && (!have_srcloc) && have_descr ) {
/* no srcloc:
- Address 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2,
+ Location 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2,
a global variable
*/
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside %s%s,",
+ "Location 0x%lx is %lu byte%s inside %s%s,",
data_addr, residual_offset, ro_plural, var->name,
VG_(indexXA)(described,0) );
VG_(snprintf)(
@@ -1776,11 +1776,11 @@
}
else
if ( frameNo >= -1 && have_srcloc && have_descr ) {
- /* Address 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2,
+ /* Location 0x7fefff6cf is 2 bytes inside a[3].xyzzy[21].c2,
a global variable declared at dsyms7.c:17 */
VG_(snprintf)(
dname1, n_dname,
- "Address 0x%lx is %lu byte%s inside %s%s,",
+ "Location 0x%lx is %lu byte%s inside %s%s,",
data_addr, residual_offset, ro_plural, var->name,
VG_(indexXA)(described,0) );
VG_(snprintf)(
Modified: branches/DATASYMS/helgrind/hg_main.c
===================================================================
--- branches/DATASYMS/helgrind/hg_main.c 2008-02-21 20:32:57 UTC (rev 7433)
+++ branches/DATASYMS/helgrind/hg_main.c 2008-02-22 01:19:49 UTC (rev 7434)
@@ -48,6 +48,7 @@
#include "pub_tool_options.h"
#include "pub_tool_xarray.h"
#include "pub_tool_stacktrace.h"
+#include "pub_tool_debuginfo.h" /* VG_(get_data_description) */
#include "helgrind.h"
@@ -7823,6 +7824,8 @@
SVal old_state;
ExeContext* mb_lastlock;
Thread* thr;
+ Char descr1[96];
+ Char descr2[96];
} Race;
struct {
Thread* thr; /* doing the freeing */
@@ -7912,6 +7915,20 @@
// FIXME: tid vs thr
tl_assert(isWrite == False || isWrite == True);
tl_assert(szB == 8 || szB == 4 || szB == 2 || szB == 1);
+
+ tl_assert(sizeof(xe.XE.Race.descr1) == sizeof(xe.XE.Race.descr2));
+ xe.XE.Race.descr1[0] = xe.XE.Race.descr2[0] = 0;
+ if (VG_(get_data_description)(
+ &xe.XE.Race.descr1[0],
+ &xe.XE.Race.descr2[0],
+ sizeof(xe.XE.Race.descr1)-1,
+ data_addr )) {
+ tl_assert( xe.XE.Race.descr1
+ [ sizeof(xe.XE.Race.descr1)-1 ] == 0);
+ tl_assert( xe.XE.Race.descr2
+ [ sizeof(xe.XE.Race.descr2)-1 ] == 0);
+ }
+
VG_(maybe_record_error)( map_threads_reverse_lookup_SLOW(thr),
XE_Race, data_addr, NULL, &xe );
}
@@ -8447,6 +8464,12 @@
old_state, old_buf, new_state, new_buf);
}
+ /* If we have a better description of the address, show it. */
+ if (xe->XE.Race.descr1[0] != 0)
+ VG_(message)(Vg_UserMsg, " %s", &xe->XE.Race.descr1);
+ if (xe->XE.Race.descr2[0] != 0)
+ VG_(message)(Vg_UserMsg, " %s", &xe->XE.Race.descr2);
+
break; /* case XE_Race */
} /* case XE_Race */
|
|
From: Nicholas N. <nj...@cs...> - 2008-02-22 00:58:34
|
On Fri, 22 Feb 2008, Julian Seward wrote:
>> I thought we had such an event -- I thought Josef used it in Callgrind.
>> In include/pub_tool_tooliface.h I see:
>>
>> track_start_client_code
>> track_stop_client_code
>> track_pre_thread_ll_create
>> track_pre_thread_ll_create
>> track_pre_thread_ll_exit
>>
>> Are any of these good enough? (I really thought we had a
>> track_thread_switch event...)
>
> Indeed we do; track_{start,stop}_client code should provide the
> required info.
Perhaps the comment in pub_tool_tooliface.h could be clarified -- it wasn't
clear to me (and presumably others) that this means "thread switch has
occurred".
Nick
|
|
From: Julian S. <js...@ac...> - 2008-02-21 23:33:44
|
> I thought we had such an event -- I thought Josef used it in Callgrind.
> In include/pub_tool_tooliface.h I see:
>
> track_start_client_code
> track_stop_client_code
> track_pre_thread_ll_create
> track_pre_thread_ll_create
> track_pre_thread_ll_exit
>
> Are any of these good enough? (I really thought we had a
> track_thread_switch event...)
Indeed we do; track_{start,stop}_client code should provide the
required info.
J
|
|
From: Nicholas N. <nj...@cs...> - 2008-02-21 21:20:28
|
On Thu, 21 Feb 2008, Bart Van Assche wrote: > On Thu, Feb 21, 2008 at 6:38 PM, Vince Weaver <vi...@cs...> wrote: >> To do this properly, it would be nice if it were possible to be notified >> whenever a thread-change happened. That way the statistics from the >> various threads could be kept separately. > > This would be useful for exp-drd too. What I do now is to compare the > result of VG_(get_running_tid)() with a cached value in order to > detect when Valgrind scheduled another thread. This test is performed > upon every load, every store, and every time the stack pointer is > modified. I thought we had such an event -- I thought Josef used it in Callgrind. In include/pub_tool_tooliface.h I see: track_start_client_code track_stop_client_code track_pre_thread_ll_create track_pre_thread_ll_create track_pre_thread_ll_exit Are any of these good enough? (I really thought we had a track_thread_switch event...) Nick |
|
From: Nicholas N. <nj...@cs...> - 2008-02-21 21:16:25
|
On Thu, 21 Feb 2008, Bart Van Assche wrote: >> One of the things I have come to realise in the past year or so >> is what a terrible programming model explicit shared-memory parallelism >> is. It's simply too hard for humans to understand and reason about >> (in all but the most trivial of applications): even small threaded >> programs are extremely hard to make sense of. > > It depends. Although understanding concurrent activities is always > hard, it is possible to write multithreaded software that is > relatively easy to read and to maintain. What I have learned during > the past ten years about writing multithreaded software is a.o. the > following: So basically you need various higher-level abstractions layered over pthreads, plus a strong dose of programmer discipline. So it's doable, but hoping everyone will get it right is optimistic. N |
|
From: <sv...@va...> - 2008-02-21 20:32:56
|
Author: bart Date: 2008-02-21 20:32:57 +0000 (Thu, 21 Feb 2008) New Revision: 7433 Log: Added a section about programming with threads, added an acknowledgements section and added more references. Modified: trunk/exp-drd/docs/README.txt Modified: trunk/exp-drd/docs/README.txt =================================================================== --- trunk/exp-drd/docs/README.txt 2008-02-21 13:19:36 UTC (rev 7432) +++ trunk/exp-drd/docs/README.txt 2008-02-21 20:32:57 UTC (rev 7433) @@ -14,24 +14,28 @@ to and reading from the shared memory. Since the invention of the multithreading concept, there is an ongoing debate about which way to model concurrent activities is better -- shared memory programming or -message passing [Ousterhout 1996]. This debate exists because each -model has significant advantages and disadvantages. While shared -memory programming relieves the programmer from writing code for the -exchange of data between concurrent activities and while shared memory -programming has a performance advantage over message passing, shared -memory programming is error prone. Shared memory programs can exhibit -data races and/or deadlocks. Data races are harmful because these may -lead to unpredictable results and nondeterministic behavior in -multithreaded programs. There are two ways to detect data races and -deadlocks: static analysis and runtime detection by a tool. Since -there do not yet exist any tools that can carry out static analysis of -data races or deadlocks, the only option to statically detect such -anomolies is source reading by a human. It takes a huge effort however -to detect all possible data races or deadlocks via source -reading. This is why tools for detecting data races and deadlocks at -runtime are essential. +message passing. This debate exists because each model has significant +advantages and disadvantages. While shared memory programming relieves +the programmer from writing code for the exchange of data between +concurrent activities and while shared memory programming has a +performance advantage over message passing, shared memory programming +is error prone. Shared memory programs can exhibit data races and/or +deadlocks. Data races are harmful because these may lead to +unpredictable results and nondeterministic behavior in multithreaded +programs. There are two ways to detect data races and deadlocks: +static analysis and runtime detection by a tool. Since there do not +yet exist any tools that can carry out static analysis of data races +or deadlocks, the only option to statically detect such anomalies is +source reading by a human. It takes a huge effort however to detect +all possible data races or deadlocks via source reading. This is why +tools for detecting data races and deadlocks at runtime are essential. +The de facto standard library for multithreading on Unix systems is +the POSIX threads library, also known as pthreads. The exp-drd tool +has been developed for multithreaded software that uses the POSIX +threads library. + Data Races ---------- @@ -115,8 +119,95 @@ tests than Helgrind. +Programming with Threads +------------------------ + +The difficulties with shared memory programming are well known and +have been outlined in more than one paper [Ousterhout 1996, Lee +2006]. It is possible however to develop and to debug multithreaded +shared memory software with a reasonable effort, even for large +applications (more than one million lines of code). In what follows an +approach is explained that has proven to work in practice. Before you +decide to use another approach, make sure you understand very well the +consequences of doing so. + +1. Use of synchronization calls. + +Do not call synchronization functions directly but use objects that +encapsulate the mutex, Mesa monitor and reader/writer locking policies. +Never use POSIX condition variables directly, since direct use of +condition variables can easily introduce race conditions. And never +lock or unlock mutexes explicitly -- use scoped locking instead. + +2. Data hiding. + +It is very important in multithreaded software to hide data that is +shared over threads. Make sure that all shared data is declared as +private data members of a class (not public, not protected). Design +the classes that contain shared data such that the number of data +members and the number of member functions is relatively small. Define +accessor functions as needed for querying and modifying member +data. Declare the associated locking objects also as private data +members, and document which locking object protects which data +members. Make sure that the query functions return a copy of data +members instead of a reference -- returning a reference would violate +data hiding anyway. This approach has a big advantage, namely that +correct use of a locking policy can be verified by reviewing one class +at a time. + +3. Modularity and hierarchy. + +For multithreaded software it is even more important than for single +threaded software that the software has a modular structure and that +there exists a hierarchy between modules. This way every call of a +function to another function can be classified as either a regular +function call (a call from a higher level to a lower level), a +callback (a call from a lower level to a higher level) or a recursive +function call. + +4. Avoiding deadlocks. + +Deadlocks can be nasty to solve since some deadlocks are very hard to +reproduce. Prevent deadlocks instead of waiting until one pops +up. Preventing deadlocks is possible by making sure that whenever two +or more mutexes are locked simultaneously, these mutexes are always +locked in the same order. One way to ensure this is by assigning each +mutex a locking order and by verifying the locking order at runtime. +This reduces the complexity of testing for absence of deadlocks from a +multithreaded to a single-threaded problem, which is a huge win. In +order to verify a locking order policy at run time, one can either use +a threading library with built-in support for verifying such a policy +or one can use a tool that verifies the locking order. + +Make sure that no mutexes are locked while invoking a callback +(calling a function from a higher level module) -- invoking a +callback while a mutex is locked is a well known way to trigger +a deadlock. + +5. Real-time software + +Software with hard real-time constraints is a special case. There +exist real-time applications that must be able to generate a response +within e.g. 1 ms after a certain input has been received. The proper +way to implement time-critical paths is not to call any function in +that path for which it is not known how long the function call will +take. Exmples for Linux of actions with an unknown call time are: +- Locking a mutex. +- Dynamic memory allocation via e.g. malloc() since malloc() internally +uses mutexes. +- File I/O, since file I/O uses several resources that are shared over +threads and even over processes. + +An approach that has proven to work for interthread communication +between real-time threads is the use of preallocated fixed size +message queueus, and to lock any data needed by any real-time thread +in memory (mlock()). Avoid mutexes with priority inheritance -- see +also [Yodaiken 2004] for more information. + + How to use DRD -------------- + To use this tool, specify --tool=drd on the Valgrind command line. @@ -133,9 +224,43 @@ * Elimination of several artificial limitations. +Acknowledgements +---------------- + +The exp-drd tool is built on top of the Valgrind core and VEX, which +proved to be an excellent infrastructure for building such a tool. + +During 2006, the early versions of drd were improved via helpful +feedback of Julian Seward and Nicholas Nethercote. Any bugs are my +responsibility of course. + +Some of the regression tests used to test exp-drd were developed by +Julian Seward as regression tests for the Helgrind tool. + +I would also like to thank Michiel Ronsse for introducing me a long +time ago to vector clocks and the JiTI and DIOTA projects. + + References ---------- +[Hansen 1972] + Per Brinch Hansen + A Comparison of Two Synchronizing Concepts. + Acta Informatica, 1 3(1972), pp. 190--199. + +[Dijkstra 1974] + Edsger W. Dijkstra. + Over seinpalen (About Semaphores). + Circulated privately (never published), 1974. + http://www.cs.utexas.edu/users/EWD/transcriptions/EWD00xx/EWD74.html + +[Hoare 1974] + C. A. R. Hoare. + Monitors: an operating system structuring concept + Communications of the ACM, October 1974, Vol. 17 No. 10, 1974. + http://www.cs.wisc.edu/~remzi/Classes/736/Fall2003/Papers/hoare-monitors.pdf + [Lamport 1978] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. @@ -143,6 +268,22 @@ http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf http://portal.acm.org/citation.cfm?id=359563 +[Accetta 1986] + Mike Accetta, Robert Baron, William Bolosky, David Golub, Richard Rashid, + Avadis Tevanian and Michael Young. + Mach: A New Kernel Foundation For UNIX Development. + USENIX 1986 (Atlanta. Ga., June 9-13), pp. 93-112, 1986. + http://www.fsl.cs.sunysb.edu/~gopalan/seminar/papers/mach.pdf + +[Young 1987] + Michael Young, Avadis Tevanian, Richard Rashid, David Golub, + Jeffrey Eppinger, Jonathan Chew, William Bolosky, David Black, Robert Baron. + The duality of memory and communication in the implementation of a + multiprocessor operating system. + ACM Symposium on Operating Systems Principles, pp. 63-76, 1987. + http://csalpha.ist.unomaha.edu/~stanw/papers/csci8550/87-duality.pdf + http://portal.acm.org/citation.cfm?id=41457.37507 + [Netzer 1992] Robert H. B. Netzer and Barton P. Miller. What are race conditions? Some issues and formalizations. @@ -186,12 +327,19 @@ Lecture Notes in Computer Science, pp. 82-89, 2004. http://escher.elis.ugent.be/publ/Edocs/DOC/P104_076.pdf +[Yodaiken 2004] + Victor Yodaiken. + Against Priority Inheritance. + FSMLabs Technical Report, 2004. + http://www.yodaiken.com/papers/inherit.pdf + [Banerjee 2006a] Utpal Banerjee, Brian Bliss, Zhiqiang Ma, Paul Petersen. Unraveling Data Race Detection in the Intel® Thread Checker. First Workshop on Software Tools for Multi-core Systems (STMCS), in conjunction with IEEE/ACM International Symposium on Code Generation and Optimization (CGO), March 26, 2006, Manhattan, New York, NY. + http://www.isi.edu/~kintali/stmcs06/UnravelingDataRace.pdf [Banerjee 2006b] Utpal Banerjee, Brian Bliss, Zhiqiang Ma, Paul Petersen. @@ -201,6 +349,13 @@ http://www.cs.ucsb.edu/~tiwari/papers/threadchecker06 http://portal.acm.org/citation.cfm?id=1147416 +[Lee 2006] + Edward A. Lee. + The Problem with Threads. + IEEE Computer, Volume 39, Issue 5 (May 2006), pp. 33-42, 2006. + http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf + http://portal.acm.org/citation.cfm?id=1137232.1137289 + [Lu 2006] Shan Lu, Joseph Tucek, Feng Qin, Yuanyuan Zhou. AVIO: detecting atomicity violations via access interleaving invariants. @@ -220,7 +375,7 @@ [Müehlenfeld 2007] Arndt Müehlenfeld, Franz Wotawa. - Fault detection in multi-threaded c++ server applications. + Fault Detection in Multi-threaded C++ Server Applications. Proceedings of the 12th ACM SIGPLAN symposium on Principles and practice of parallel programming, San Jose, California, USA, poster session, pp. 142-143, 2007. |
|
From: Bart V. A. <bar...@gm...> - 2008-02-21 19:01:13
|
On Thu, Feb 21, 2008 at 6:38 PM, Vince Weaver <vi...@cs...> wrote: > To do this properly, it would be nice if it were possible to be notified > whenever a thread-change happened. That way the statistics from the > various threads could be kept separately. This would be useful for exp-drd too. What I do now is to compare the result of VG_(get_running_tid)() with a cached value in order to detect when Valgrind scheduled another thread. This test is performed upon every load, every store, and every time the stack pointer is modified. Bart. |