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
|
2
(2) |
3
(7) |
|
4
|
5
(11) |
6
(13) |
7
(7) |
8
(5) |
9
(12) |
10
(19) |
|
11
(12) |
12
(7) |
13
(14) |
14
(8) |
15
(5) |
16
(5) |
17
(7) |
|
18
(12) |
19
(14) |
20
(12) |
21
(8) |
22
(4) |
23
(4) |
24
|
|
25
(11) |
26
(17) |
27
(15) |
28
(10) |
29
(19) |
30
(18) |
|
|
From: ilya s. <ily...@gm...> - 2011-09-19 21:40:58
|
>you have some concrete use case in mind. What do you want to
>accomplish in the end?
Say valgrind shows that I'm spending 60% of time in function myFunc(),
and now I want to optimize myFunc().
Say myFunc is called 1,000,000 times, but 60% of its total runtime is spent
in 5% of these calls. I want to (1) know that this is the case (hence
the histograms), and
(2) get a look at these 5% of calls -- what is it about the arguments
to these calls, that
makes myFunc() take disproportionate time on them? (hence the
VALGRIND_SHOULD_PRINT client request).
When implementing a function or choosing a data structure there is
often a tradeoff: you can speed it up
on some inputs while slowing it down on others.
E.g. if your function processes, lists, you might add special-case
checks and code for short lists,
which will speed things up for short lists but slow things down for
longer lists that don't fall under
the special cases. Having histograms would tell you what fraction of
time gets spent on longer vs shorter lists.
If a histogram shows that the bulk of time is spent on a small
fraction of calls that each take >100,000 instructions,
I want to examine some of these calls -- specifically, the inputs to
them. The VALGRIND_SHOULD_PRINT client request
would let me do that.
I've been doing this manually by manually timing myFunc(), building a
histogram of its runtimes, finding which bins
dominate the histogram; then, looking at the inputs of some
representative invocations that fall in these runtime bins,
by: putting a static counter inside the function so you know when
you're on its N'th invocation; printing the counter
value for the first few invocations whose runtime falls into the bins
of interest; then adding code at the start of function,
"if counter == one of the printed counter values, print the function arguments".
Building this into the profiler would let me 1) avoid doing the above
for each function I want to optimize, and 2) do this
not just for runtime but for all other statistics gathered by
cachegrind/callgrind.
Does this explanation help, or should I write some more detailed examples?
>If writing millions of files is to expensive,
it would be too expensive in my case.
>easier to think about a way to pass measurements to a script
>in a more light-weight way (e.g. via pipes). You should
>be able to implement your suggestions in your own script then.
thanks, that might work for making histograms (esp. if I limit
data-gathering to that one function).
but it wouldn't work for printing the arguments of some representative
function invocations falling into a given range of runtimes.
ilya
On Mon, Sep 19, 2011 at 4:24 PM, Josef Weidendorfer
<Jos...@gm...> wrote:
> Hi Ilya,
>
> On Monday 19 September 2011, ilya shlyakhter wrote:
>> how hard would it be to implement the following extension to
>> cachegrind/callgrind:
>> ...
>
> this list (which I do not understand completely) suggests that
> you have some concrete use case in mind. What do you want to
> accomplish in the end?
>
>> right now, when reporting the cost of a function, the cost of all
>> invocations is aggregated together.
>> (callgrind separates the invocations by caller, but that's as
>> fine-grained as it goes).
>
> Hmm.. you can also dump counters to a file anytime you want,
> e.g. with "--dump-after=<func>". You then can post-process
> the files, and do your own statistics on it.
> For how to parse the files in PERL, see "callgrind_annotate".
>
> If writing millions of files is to expensive, it probably is
> easier to think about a way to pass measurements to a script
> in a more light-weight way (e.g. via pipes). You should
> be able to implement your suggestions in your own script then.
>
>> the proposed extension would do the following:
>> - for each function (or for requested functions), for a chosen
>> statistic (Ir, DLmr, etc), produce a _histogram_ of invocation costs.
>> in each bin, keep the # of invocations and their total cost.
>
>> an additional extension would let the user print their own debug
>> information for representative
>> invocations falling into a given bin. this would work only for
>> completely deterministic user programs.
>> - there would be a valgrind client request, VALGRIND_SHOULD_PRINT,
>> which the user would
>> add to their function to tell them whether to print debug
>> information for this invocation:
>>
>> void myFunc( ComplexStructure *arg ) {
>> if( VALGRIND_SHOULD_PRINT )
>> arg->print();
>> ...
>> }
>> - there would be an option to cachegrind/callgrind to record and
>> save in an output file, for a given function and
>> a given range of costs, the "invocation ids" of some small number
>> of invocations of that function in that cost range.
>> "invocation id" of a function is simply the order number of its
>> invocation (e.g. the 134701st invocation of this function).
>>
>> - there would be another option to cachegrind/callgrind to read the
>> file recorded above and to have VALGRIND_SHOULD_PRINT return 1
>> for the recorded invocations, and 0 for all others.
>
> I don't understand the benefit. How would you use that feature?
>
>> this would allow finer-grained profiling than is currently possible.
>> how hard would this be to add?
>
> If you come up with a patch, you still need to prove that it is worth
> merging and maintaining. It seems easier to me to try to come up
> with a general solution which allows users to implement their own
> post-processing/statistics, as mentioned above.
>
> E.g. for adding histograms, you not only need to change cachegrind/callgrind,
> but also extend the format and parsers, such as {cg,callgrind}_annotate,
> and the KCachegrind GUI.
>
> That said, it would be cool to have histograms.
>
> Josef
>
>>
>> thanks,
>>
>> ilya
>>
>> ------------------------------------------------------------------------------
>> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
>> Learn about the latest advances in developing for the
>> BlackBerry® mobile platform with sessions, labs & more.
>> See new tools and technologies. Register for BlackBerry® DevCon today!
>> http://p.sf.net/sfu/rim-devcon-copy1
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>
>
>
|
|
From: Christian B. <bor...@de...> - 2011-09-19 20:35:25
|
Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2011-09-19 22:05:01 CEST Ended at 2011-09-19 22:35:09 CEST 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 == 499 tests, 14 stderr failures, 0 stdout failures, 8 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/mcbreak (stderrB) gdbserver_tests/mcclean_after_fork (stderrB) gdbserver_tests/mcleak (stderrB) gdbserver_tests/mcmain_pic (stderrB) gdbserver_tests/mcvabits (stderrB) gdbserver_tests/mssnapshot (stderrB) gdbserver_tests/nlpasssigalrm (stderrB) gdbserver_tests/nlsigvgdb (stderrB) memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) memcheck/tests/linux/timerfd-syscall (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) |
|
From: Josef W. <Jos...@gm...> - 2011-09-19 20:24:33
|
Hi Ilya,
On Monday 19 September 2011, ilya shlyakhter wrote:
> how hard would it be to implement the following extension to
> cachegrind/callgrind:
> ...
this list (which I do not understand completely) suggests that
you have some concrete use case in mind. What do you want to
accomplish in the end?
> right now, when reporting the cost of a function, the cost of all
> invocations is aggregated together.
> (callgrind separates the invocations by caller, but that's as
> fine-grained as it goes).
Hmm.. you can also dump counters to a file anytime you want,
e.g. with "--dump-after=<func>". You then can post-process
the files, and do your own statistics on it.
For how to parse the files in PERL, see "callgrind_annotate".
If writing millions of files is to expensive, it probably is
easier to think about a way to pass measurements to a script
in a more light-weight way (e.g. via pipes). You should
be able to implement your suggestions in your own script then.
> the proposed extension would do the following:
> - for each function (or for requested functions), for a chosen
> statistic (Ir, DLmr, etc), produce a _histogram_ of invocation costs.
> in each bin, keep the # of invocations and their total cost.
> an additional extension would let the user print their own debug
> information for representative
> invocations falling into a given bin. this would work only for
> completely deterministic user programs.
> - there would be a valgrind client request, VALGRIND_SHOULD_PRINT,
> which the user would
> add to their function to tell them whether to print debug
> information for this invocation:
>
> void myFunc( ComplexStructure *arg ) {
> if( VALGRIND_SHOULD_PRINT )
> arg->print();
> ...
> }
> - there would be an option to cachegrind/callgrind to record and
> save in an output file, for a given function and
> a given range of costs, the "invocation ids" of some small number
> of invocations of that function in that cost range.
> "invocation id" of a function is simply the order number of its
> invocation (e.g. the 134701st invocation of this function).
>
> - there would be another option to cachegrind/callgrind to read the
> file recorded above and to have VALGRIND_SHOULD_PRINT return 1
> for the recorded invocations, and 0 for all others.
I don't understand the benefit. How would you use that feature?
> this would allow finer-grained profiling than is currently possible.
> how hard would this be to add?
If you come up with a patch, you still need to prove that it is worth
merging and maintaining. It seems easier to me to try to come up
with a general solution which allows users to implement their own
post-processing/statistics, as mentioned above.
E.g. for adding histograms, you not only need to change cachegrind/callgrind,
but also extend the format and parsers, such as {cg,callgrind}_annotate,
and the KCachegrind GUI.
That said, it would be cool to have histograms.
Josef
>
> thanks,
>
> ilya
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> Learn about the latest advances in developing for the
> BlackBerry® mobile platform with sessions, labs & more.
> See new tools and technologies. Register for BlackBerry® DevCon today!
> http://p.sf.net/sfu/rim-devcon-copy1
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
|
|
From: Christian B. <bor...@de...> - 2011-09-19 20:10:58
|
Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) ) Started at 2011-09-19 21:45:01 CEST Ended at 2011-09-19 22:11:07 CEST 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 == 498 tests, 13 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) memcheck/tests/linux/timerfd-syscall (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) |
|
From: ilya s. <ily...@gm...> - 2011-09-19 17:30:33
|
dear valgrind developers,
how hard would it be to implement the following extension to
cachegrind/callgrind:
right now, when reporting the cost of a function, the cost of all
invocations is aggregated together.
(callgrind separates the invocations by caller, but that's as
fine-grained as it goes).
the proposed extension would do the following:
- for each function (or for requested functions), for a chosen
statistic (Ir, DLmr, etc), produce a _histogram_ of invocation costs.
in each bin, keep the # of invocations and their total cost.
this will show e.g. how much you'd save by optimizing the cheap
common cases,
vs. the costly rare cases.
an additional extension would let the user print their own debug
information for representative
invocations falling into a given bin. this would work only for
completely deterministic user programs.
- there would be a valgrind client request, VALGRIND_SHOULD_PRINT,
which the user would
add to their function to tell them whether to print debug
information for this invocation:
void myFunc( ComplexStructure *arg ) {
if( VALGRIND_SHOULD_PRINT )
arg->print();
...
}
- there would be an option to cachegrind/callgrind to record and
save in an output file, for a given function and
a given range of costs, the "invocation ids" of some small number
of invocations of that function in that cost range.
"invocation id" of a function is simply the order number of its
invocation (e.g. the 134701st invocation of this function).
- there would be another option to cachegrind/callgrind to read the
file recorded above and to have VALGRIND_SHOULD_PRINT return 1
for the recorded invocations, and 0 for all others.
this would allow finer-grained profiling than is currently possible.
how hard would this be to add?
thanks,
ilya
|
|
From: Julian S. <js...@ac...> - 2011-09-19 16:47:49
|
> > * first, figure out if the error is in gcc or valgrind. Use addr2line > > to map the code addresses shown by valgrind back to line numbers, > > independent of valgrind's mechanism for that, to see what you get. > > The addresses and line numbers that valgrind reports do correspond with > addr2line, so it seems the addresses themselves must be wrong. Ok .. so V's address-to-line mapping is OK, at least. > > out of date guest register values appear in the unwinder. Do > > any of the following flags (independently, not in combination) > > change the results? > > --vex-iropt-precise-memory-exns=yes > > --vex-iropt-level=0 > > --vex-guest-max-insns=1 > > None of these helped, so I'll get some detailed debugging output using > --trace-flags. Strange that these don't make any difference. It would be useful to get the just-before-instruction-selection IR for the block containing the client request, to see if there's anything amiss there. Another question is: does the inaccuracy happen on the innermost frame, or also on non-innermost frames? If on the innermost frame then we can discount any wierdness caused by the stack unwinder, since the PC for the innermost frame is take directly from the guest PC (guest_CIA) unmodified. J |
|
From: <sv...@va...> - 2011-09-19 15:19:23
|
Author: de Date: 2011-09-19 16:14:34 +0100 (Mon, 19 Sep 2011) New Revision: 438 Log: Updated front page menu in the hope users can find the Valkyrie entry more easily. See bug #251406 Modified: trunk/php/menu.php Modified: trunk/php/menu.php =================================================================== --- trunk/php/menu.php 2011-09-19 15:13:11 UTC (rev 437) +++ trunk/php/menu.php 2011-09-19 15:14:34 UTC (rev 438) @@ -11,9 +11,9 @@ $source_code = array( array( 'url'=>'current.html', 'tag'=>'Current Releases' ), array( 'url'=>'old.html', 'tag'=>'Release Archive' ), - array( 'url'=>'guis.html', 'tag'=>'Front Ends / GUIs' ), array( 'url'=>'variants.html', 'tag'=>'Variants / Patches' ), - array( 'url'=>'repository.html','tag'=>'Code Repository' ) + array( 'url'=>'repository.html','tag'=>'Code Repository' ), + array( 'url'=>'guis.html', 'tag'=>'Valkyrie / GUIs' ) ); $docs = array( |
|
From: <sv...@va...> - 2011-09-19 15:17:59
|
Author: de Date: 2011-09-19 16:13:11 +0100 (Mon, 19 Sep 2011) New Revision: 437 Log: Updates guis page to give valkyrie a bit of virtual real estate, see bug #251406. Modified: trunk/downloads/guis.html Modified: trunk/downloads/guis.html =================================================================== --- trunk/downloads/guis.html 2011-06-27 16:22:44 UTC (rev 436) +++ trunk/downloads/guis.html 2011-09-19 15:13:11 UTC (rev 437) @@ -1,8 +1,30 @@ + <h1>Graphical User Interfaces</h1> -<p>One of the most asked for features for Valgrind is a graphical -user interface to help with configuration and use. -Several graphical front-ends have been built for Valgrind. These +<p>One of the most requested features for Valgrind is a graphical user +interface to help with use and configuration.</p> + +<p><b>Valkyrie</b> is a Qt4-based GUI for the Memcheck and Helgrind +tools in the Valgrind 3.6.X line, developed and maintained by the +Valgrind Developers. Valkyrie also includes an auxiliary tool which +merges XML output from multiple Memcheck runs into a single XML file, +and optionally displays the merged result in the GUI. You can see +some <a href="http://www.open-works.net/projects/valkyrie.html">screenshots +here</a>.</p> + +<p>The complete source code for the current release, including +documentation, is available as a tarball from the +<a href="/downloads/current.html">Valgrind download page</a>.<br /> +The code under active development is in a Subversion repository (and may not work properly). To check out Valkyrie via anonymous, read-only svn access:<br /> +<tt>svn co svn://svn.valgrind.org/valkyrie/trunk valkyrie</tt></p> + + +<hr /> + + +<h2>Other GUIs</h2> + +<p>Several other graphical front-ends have been built for Valgrind. These are the ones we know about.</p> <ul> @@ -30,15 +52,6 @@ Estievenart.</p></li> -<li><p><a href="http://www.open-works.net/projects/valkyrie.html">Valkyrie</a> -is a Qt4-based GUI for the Memcheck and Helgrind tools in the Valgrind 3.6.X line. -You can download the latest version (2.0.0, for use with Valgrind 3.6.0 -and later) from the <a href="/downloads/current.html">Valgrind download page</a>. -Valkyrie also includes an auxiliary tool which merges XML output from -multiple Memcheck runs into a single XML file, and optionally displays -the merged result in the GUI.</p></li> - - </ul> <p> </p> |
|
From: Maynard J. <may...@us...> - 2011-09-19 13:51:15
|
Julian Seward wrote: > > I've long noticed this on ppc64, but never chased it. There are a couple > of things you could do: > > * first, figure out if the error is in gcc or valgrind. Use addr2line > to map the code addresses shown by valgrind back to line numbers, > independent of valgrind's mechanism for that, to see what you get. The addresses and line numbers that valgrind reports do correspond with addr2line, so it seems the addresses themselves must be wrong. I also compared the compile commands for memcheck/tests/addressable between 3.6.1 and SVN and they look equivalent. I even copy/pasted the 3.6.1 compile line and used it in my svn devel tree, but that made no difference when running the testcase. > > * see if it's to do with vex's IR level optimisations making slightly > out of date guest register values appear in the unwinder. Do > any of the following flags (independently, not in combination) > change the results? > --vex-iropt-precise-memory-exns=yes > --vex-iropt-level=0 > --vex-guest-max-insns=1 None of these helped, so I'll get some detailed debugging output using --trace-flags. -Maynard > > J > > On Saturday, September 17, 2011, Maynard Johnson wrote: >> I am doing some validation of the latest valgrind code on some ppc64 >> systems. One problem I've run into is that a number of memcheck/tests are >> failing because the stderr output shows some line numbers that are off by >> 1-3 lines compared to what's expected. I'm not seeing this on x86 -- just >> ppc64. For example, memcheck/tests/addressable fails as follows: >> >> ---------------------------------- >> --- addressable.stderr.exp 2011-09-14 12:08:53.000000000 -0500 >> +++ addressable.stderr.out 2011-09-14 12:47:35.000000000 -0500 >> @@ -9,7 +9,7 @@ >> For counts of detected and suppressed errors, rerun with: -v >> ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) >> Unaddressable byte(s) found during client check request >> - at 0x........: test2 (addressable.c:48) >> + at 0x........: test2 (addressable.c:51) >> by 0x........: main (addressable.c:125) >> Address 0x........ is not stack'd, malloc'd or (recently) free'd >> >> ---------------------------------- >> >> Notably, the same testcase runs fine in valgrind 3.6.1. And I see no >> changes to the testcase or expected output between 3.6.1 and current SVN >> code. I see this problem on both ppc64 systems I've tested on so far, one >> being a POWER7/SLES 11 SP1 and the other a POWER5/SLES 10 SP3. Does >> anyone have any idea what may have changed in regards to debuginfo >> collection between 3.6.1 and present? I'll continue to dig, but hoping >> someone can short-circuit the search by pointing me in the right >> direction. >> >> Thanks. >> -Maynard >> >> >> --------------------------------------------------------------------------- >> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> http://p.sf.net/sfu/rim-devcon-copy2 >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: <br...@ac...> - 2011-09-19 08:22:10
|
valgrind revision: 12039 VEX revision: 2201 GCC version: gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) GLIBC version: GNU C Library stable release version 2.3.4, by Roland McGrath et al. uname -mrs: Linux 2.6.9-42.EL s390x Vendor version: Red Hat Enterprise Linux AS release 4 (Nahant Update 4) Nightly build on z900 ( s390x build on z900 ) Started at 2011-09-19 01:42:22 EDT Ended at 2011-09-19 04:28:31 EDT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 465 tests, 18 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/varinfo6 (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 465 tests, 20 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/varinfo6 (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) drd/tests/annotate_hb_race (stderr) drd/tests/tc04_free_lock (stderr) drd/tests/tc09_bad_unlock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Sep 19 03:04:22 2011 --- new.short Mon Sep 19 04:28:31 2011 *************** *** 8,10 **** ! == 465 tests, 20 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable3 (stderr) --- 8,10 ---- ! == 465 tests, 18 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable3 (stderr) *************** *** 23,28 **** helgrind/tests/tc12_rwl_trivial (stderr) - helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) - drd/tests/annotate_hb_race (stderr) drd/tests/tc04_free_lock (stderr) --- 23,26 ---- |
|
From: Julian S. <js...@ac...> - 2011-09-19 03:59:58
|
> So, a possible cause for the difference might be in the code generated > byValgrind (e.g. for the client request and the maintenance of the > simulated program counter) : if the code emitted for the client request > does not store back the exact program counter to the VEX state before > doing the client request, then both Valgrind and gdb unwinder will wrongly > show another program counter. > E.g. I do not know how the Valgrind optimiser is informed that a client > request can e.g. read various registers and so that the state of these > must be properly put back to the VEX state before doing the call ? This was my first guess too. But the thing is, AFAIR vex makes all guest registers be up to date before doing a client request, because a client request terminates a superblock, and all guest registers are up to date at the end of a superblock -- at least in this case, when the dispatch-ppc64-linux.S dispatcher returns to m_scheduler in order to carry out the client request. So I am not sure what's going on here. J |
|
From: Julian S. <js...@ac...> - 2011-09-19 03:55:23
|
I've long noticed this on ppc64, but never chased it. There are a couple of things you could do: * first, figure out if the error is in gcc or valgrind. Use addr2line to map the code addresses shown by valgrind back to line numbers, independent of valgrind's mechanism for that, to see what you get. * see if it's to do with vex's IR level optimisations making slightly out of date guest register values appear in the unwinder. Do any of the following flags (independently, not in combination) change the results? --vex-iropt-precise-memory-exns=yes --vex-iropt-level=0 --vex-guest-max-insns=1 J On Saturday, September 17, 2011, Maynard Johnson wrote: > I am doing some validation of the latest valgrind code on some ppc64 > systems. One problem I've run into is that a number of memcheck/tests are > failing because the stderr output shows some line numbers that are off by > 1-3 lines compared to what's expected. I'm not seeing this on x86 -- just > ppc64. For example, memcheck/tests/addressable fails as follows: > > ---------------------------------- > --- addressable.stderr.exp 2011-09-14 12:08:53.000000000 -0500 > +++ addressable.stderr.out 2011-09-14 12:47:35.000000000 -0500 > @@ -9,7 +9,7 @@ > For counts of detected and suppressed errors, rerun with: -v > ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > Unaddressable byte(s) found during client check request > - at 0x........: test2 (addressable.c:48) > + at 0x........: test2 (addressable.c:51) > by 0x........: main (addressable.c:125) > Address 0x........ is not stack'd, malloc'd or (recently) free'd > > ---------------------------------- > > Notably, the same testcase runs fine in valgrind 3.6.1. And I see no > changes to the testcase or expected output between 3.6.1 and current SVN > code. I see this problem on both ppc64 systems I've tested on so far, one > being a POWER7/SLES 11 SP1 and the other a POWER5/SLES 10 SP3. Does > anyone have any idea what may have changed in regards to debuginfo > collection between 3.6.1 and present? I'll continue to dig, but hoping > someone can short-circuit the search by pointing me in the right > direction. > > Thanks. > -Maynard > > > --------------------------------------------------------------------------- > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <th...@cy...> - 2011-09-19 03:18:34
|
Nightly build on bristol ( x86_64, Fedora 9 ) Started at 2011-09-19 03:40:48 BST Ended at 2011-09-19 04:18:11 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 574 tests, 5 stderr failures, 4 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/err_disable3 (stderr) memcheck/tests/err_disable4 (stderr) none/tests/amd64/bug132918 (stdout) none/tests/amd64/fxtract (stdout) none/tests/amd64/sse4-64 (stdout) none/tests/x86/fxtract (stdout) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: <sv...@va...> - 2011-09-19 02:38:37
|
Author: florian Date: 2011-09-19 03:33:35 +0100 (Mon, 19 Sep 2011) New Revision: 12039 Log: Disable sending diffs for the z900 build for now. They are too big to be posted to the mailing list without moderator interaction. Modified: trunk/nightly/conf/z900.sendmail Modified: trunk/nightly/conf/z900.sendmail =================================================================== --- trunk/nightly/conf/z900.sendmail 2011-09-18 00:11:12 UTC (rev 12038) +++ trunk/nightly/conf/z900.sendmail 2011-09-19 02:33:35 UTC (rev 12039) @@ -22,7 +22,7 @@ echo "uname -mrs: $uname_stuff" >> $MAILFILE echo "Vendor version: $vendor_stuff" >> $MAILFILE echo " " >> $MAILFILE -cat "$2" >> $MAILFILE +cat "$summary" >> $MAILFILE echo " " >> $MAILFILE -cat "$3" >> $MAILFILE +# cat "$diffs" >> $MAILFILE /usr/sbin/sendmail -t -i -fb...@ac... < $MAILFILE |