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
(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: 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
|