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
(20) |
2
(19) |
3
(7) |
|
4
(13) |
5
(24) |
6
(9) |
7
(12) |
8
(8) |
9
(34) |
10
(28) |
|
11
(20) |
12
(23) |
13
(12) |
14
(10) |
15
(15) |
16
(24) |
17
(26) |
|
18
(17) |
19
(14) |
20
(14) |
21
(8) |
22
(12) |
23
(22) |
24
(10) |
|
25
(21) |
26
(21) |
27
(18) |
28
(8) |
29
(13) |
30
(15) |
|
|
From: <sv...@va...> - 2007-11-15 23:30:17
|
Author: sewardj
Date: 2007-11-15 23:30:16 +0000 (Thu, 15 Nov 2007)
New Revision: 1794
Log:
Handle the "alternative" (non-binutils) encoding of 'adc' and tidy up
some other op-G-E / op-E-G decodings. This fixes a bug which was
reported on val...@li... on 11 Aug 2007
("LibVEX called failure_exit() with 3.3.0svn-r6769 with Linux on
AMD64") I don't think it ever was formally filed as a bug report.
Modified:
trunk/priv/guest-amd64/toIR.c
Modified: trunk/priv/guest-amd64/toIR.c
===================================================================
--- trunk/priv/guest-amd64/toIR.c 2007-11-09 21:15:04 UTC (rev 1793)
+++ trunk/priv/guest-amd64/toIR.c 2007-11-15 23:30:16 UTC (rev 1794)
@@ -2509,7 +2509,6 @@
assign( src, getIRegE(size,pfx,rm) );
if (addSubCarry && op8 == Iop_Add8) {
- vassert(0); /* awaiting test case */
helper_ADC( size, dst1, dst0, src );
putIRegG(size, pfx, rm, mkexpr(dst1));
} else
@@ -13059,6 +13058,7 @@
break;
case 0x14: /* ADC Ib, AL */
+ if (haveF2orF3(pfx)) goto decode_failure;
delta = dis_op_imm_A( 1, True, Iop_Add8, True, delta, "adc" );
break;
//.. //-- case 0x15: /* ADC Iv, eAX */
@@ -13137,11 +13137,13 @@
if (haveF2orF3(pfx)) goto decode_failure;
delta = dis_op2_E_G ( pfx, False, Iop_Or8, True, sz, delta, "or" );
break;
-//--
-//.. //-- case 0x12: /* ADC Eb,Gb */
-//.. //-- delta = dis_op2_E_G ( sorb, True, ADC, True, 1, delta, "adc" );
-//.. //-- break;
+
+ case 0x12: /* ADC Eb,Gb */
+ if (haveF2orF3(pfx)) goto decode_failure;
+ delta = dis_op2_E_G ( pfx, True, Iop_Add8, True, 1, delta, "adc" );
+ break;
case 0x13: /* ADC Ev,Gv */
+ if (haveF2orF3(pfx)) goto decode_failure;
delta = dis_op2_E_G ( pfx, True, Iop_Add8, True, sz, delta, "adc" );
break;
@@ -13149,6 +13151,7 @@
//.. //-- delta = dis_op2_E_G ( sorb, True, SBB, True, 1, delta, "sbb" );
//.. //-- break;
case 0x1B: /* SBB Ev,Gv */
+ if (haveF2orF3(pfx)) goto decode_failure;
delta = dis_op2_E_G ( pfx, True, Iop_Sub8, True, sz, delta, "sbb" );
break;
|
|
From: <sv...@va...> - 2007-11-15 22:33:35
|
Author: sewardj Date: 2007-11-15 22:33:32 +0000 (Thu, 15 Nov 2007) New Revision: 7159 Log: Add a regression test for #152022. Added: trunk/memcheck/tests/x86/bug152022.c trunk/memcheck/tests/x86/bug152022.stderr.exp trunk/memcheck/tests/x86/bug152022.stdout.exp trunk/memcheck/tests/x86/bug152022.vgtest Modified: trunk/memcheck/tests/x86/Makefile.am Modified: trunk/memcheck/tests/x86/Makefile.am =================================================================== --- trunk/memcheck/tests/x86/Makefile.am 2007-11-14 15:53:11 UTC (rev 7158) +++ trunk/memcheck/tests/x86/Makefile.am 2007-11-15 22:33:32 UTC (rev 7159) @@ -6,6 +6,7 @@ EXTRA_DIST = $(noinst_SCRIPTS) \ bug133694.vgtest bug133694.stderr.exp bug133694.stdout.exp \ + bug152022.vgtest bug152022.stderr.exp bug152022.stdout.exp \ espindola2.vgtest espindola2.stderr.exp \ fpeflags.stderr.exp fpeflags.vgtest \ $(addsuffix .stderr.exp,$(INSN_TESTS)) \ @@ -31,6 +32,7 @@ check_PROGRAMS = \ bug133694 \ + bug152022 \ espindola2 \ int3-x86 \ scalar_exit_group scalar_fork scalar_supp scalar_vfork \ Added: trunk/memcheck/tests/x86/bug152022.c =================================================================== --- trunk/memcheck/tests/x86/bug152022.c (rev 0) +++ trunk/memcheck/tests/x86/bug152022.c 2007-11-15 22:33:32 UTC (rev 7159) @@ -0,0 +1,22 @@ + +/* As discussed on valgrind-users in the thread + http://comments.gmane.org/gmane.comp.debugging.valgrind/7535 + valgrinding Wine running a large win32 app (Picasa) fails with the message + + vex: priv/host-x86/isel.c:510 (doHelperCall): Assertion + `typeOfIRExpr(env->type_env, args[i]) == Ity_I32' failed. + + See http://bugs.kde.org/show_bug.cgi?id=152022 + +This little fragment used to cause Memcheck to assert, so if the +program runs to completion without dying, the test is passed. +*/ + + +int main ( void ) { + __asm__ __volatile__( "subw $0x28, %%sp\n" + "movl $0, 0(%%esp)\n" + "addw $0x28, %%sp" : : : "memory" ); + return 0; +} + Added: trunk/memcheck/tests/x86/bug152022.stderr.exp =================================================================== --- trunk/memcheck/tests/x86/bug152022.stderr.exp (rev 0) +++ trunk/memcheck/tests/x86/bug152022.stderr.exp 2007-11-15 22:33:32 UTC (rev 7159) @@ -0,0 +1,7 @@ + + +ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) +malloc/free: in use at exit: 0 bytes in 0 blocks. +malloc/free: 0 allocs, 0 frees, 0 bytes allocated. +For a detailed leak analysis, rerun with: --leak-check=yes +For counts of detected errors, rerun with: -v Added: trunk/memcheck/tests/x86/bug152022.stdout.exp =================================================================== Added: trunk/memcheck/tests/x86/bug152022.vgtest =================================================================== --- trunk/memcheck/tests/x86/bug152022.vgtest (rev 0) +++ trunk/memcheck/tests/x86/bug152022.vgtest 2007-11-15 22:33:32 UTC (rev 7159) @@ -0,0 +1 @@ +prog: bug152022 |
|
From: Nicholas N. <nj...@cs...> - 2007-11-15 21:43:26
|
On Thu, 15 Nov 2007, Josef Weidendorfer wrote: > The "global single option" was meant to be about the output file only. > Of course there also is a log output that already can be redirected > with "--log-file". But we currently do not have a per-tool option for the log > output of each tool. Why do we want different options to specify the output > file of each tool then? Ok, I think you're suggesting we have just two options, something like: --log-file: for logging output, eg. what normally goes to stderr --out-file: for tool-specific file output, eg. Cachegrind/Massif I find --out-file confusing. The difference with --log-file is not immediately clear. Also, what about tools that don't create a file, like Memcheck -- is --out-file ignored? Should it cause an abort if it's used? I think having options that all tools must implement is not a good idea. We already have some (eg. -v) but I'd like to avoid more. In comparison, if we have a --cachegrind-out-file option, it's very clear what it does, particularly if the default name is "cachegrind.out.<pid>". Nick |
|
From: Julian S. <js...@ac...> - 2007-11-15 18:43:44
|
> What is the typical slowdown of helgrind (compared to native run or > compared to memcheck)? 30 - 60 x, but is very workload dependent, much more so than memcheck > Does it depend on the number of threads/locks? It depends on a lot of things. The following are very expensive: - deleting (eg, free, delete[], stack deallocation) containing a lock - pthread_join > Do you have any suggestions on further analysis/improvements of helgrind > performance? Run (the problem program) with -v. It prints ~ 100 lines of stats at the end. Send those. J |
|
From: Konstantin S. <kon...@gm...> - 2007-11-15 16:08:43
|
Hi, I was running helgrind on various medium-sized tests and I experience an issue with helgrind's speed. One of the tests - runs ~3 seconds by itself - runs ~50 seconds under memcheck (passes) - dies after ~150 seconds completing less than 30% of work. The test simply does not like to be delayed that much -- it has too strict timeouts. The test has > 50 threads. I tried profiling the helgrind run (using oprofile) and see the following profile. samples % image name symbol name 82533 14.9762 helgrind avl_find_node <<<<<<<<< this one seem to have an indirect call of kCmp... Might be worth inlining 73035 13.2528 helgrind cacheline_wback 66704 12.1039 helgrind evh__mem_help_read_4 <<<< this one seems to be called indirectly... 55637 10.0958 anon (tgid:19421 range:0x4b2f000-0x5c55000) (no symbols) <<<< I suspect that this is the actual user's code, right? 46728 8.4791 helgrind cacheline_fetch 26357 4.7827 helgrind msm__handle_read 25291 4.5892 helgrind shadow_mem_set32 (I tested unmodified version I checked out yesterday from trunk). What is the typical slowdown of helgrind (compared to native run or compared to memcheck)? Does it depend on the number of threads/locks? Do you have any suggestions on further analysis/improvements of helgrind performance? Thanks, --kcc |
|
From: Josef W. <Jos...@gm...> - 2007-11-15 14:02:41
|
On Thursday 15 November 2007, Nicholas Nethercote wrote: > On Thu, 15 Nov 2007, Josef Weidendorfer wrote: > > >> Overall, we'd have a --log-file option for normal Valgrind output (ie. what > >> normally goes to stderr), and then for each tool that writes an output file > >> (Cachegrind, Callgrind, Massif) there would be an option like --massif-file. > >> In the Callgrind case it would be --callgrind-file-prefix. > > > > Do we really want the tool name in the option? I would vote for one global > > option "--output-file=..." to specify an output file name/pattern, and the tool > > is free to add suffixes. This makes it easier for the user to remember > > * the option name and > > * the fact that this option allows for pattern specification. > > An example: for Cachegrind, there is the "log output", ie. what normally is > printed to stderr, and there is the "file output", ie. what goes in > cachegrind.out.*. You need to be able to control the file names of these > two separately. So a single global options won't suffice. The "global single option" was meant to be about the output file only. Of course there also is a log output that already can be redirected with "--log-file". But we currently do not have a per-tool option for the log output of each tool. Why do we want different options to specify the output file of each tool then? Josef > > Nick > |
|
From: Nicholas N. <nj...@cs...> - 2007-11-15 11:07:28
|
On Thu, 15 Nov 2007, Josef Weidendorfer wrote: >> Overall, we'd have a --log-file option for normal Valgrind output (ie. what >> normally goes to stderr), and then for each tool that writes an output file >> (Cachegrind, Callgrind, Massif) there would be an option like --massif-file. >> In the Callgrind case it would be --callgrind-file-prefix. > > Do we really want the tool name in the option? I would vote for one global > option "--output-file=..." to specify an output file name/pattern, and the tool > is free to add suffixes. This makes it easier for the user to remember > * the option name and > * the fact that this option allows for pattern specification. An example: for Cachegrind, there is the "log output", ie. what normally is printed to stderr, and there is the "file output", ie. what goes in cachegrind.out.*. You need to be able to control the file names of these two separately. So a single global options won't suffice. Nick |
|
From: Josef W. <Jos...@gm...> - 2007-11-15 10:01:05
|
On Thursday 15 November 2007, Nicholas Nethercote wrote:
> I didn't really follow that, but it seems like Callgrind produces multiple
> output files. They all have a common prefix, and then each one has a
> different suffix. When it comes to processing them, presumably you give
> callgrind_annotate/KCachegrind the prefix, and then they can find all the
> extra files because they know what the suffixes look like.
Yes, that's right in the case of KCachegrind.
I assume there could be other tools in the future which produce multiple
output files. It is reasonable to expect that they all will be fine
with a user settable prefix part and a tool controlled suffix.
> In other words, it makes sense for a user to specify the prefix, but not the
> suffix, because the processing tools depend on them having a particular
> form.
>
> If I'm right, then I think we only need:
>
> %p process id
> %q{QUAL} environment variable contents
>
> %T for toolname isn't necessary, nor are %t or %c because they're not
> controllable by the user.
Hm. %t could make sense with a tool which has an output per thread.
But as there currently is no such tool, there is no need.
(for callgrind, the thread is part of the suffix which the user does not
have the need to control, so there is no need for %t there, too).
> Overall, we'd have a --log-file option for normal Valgrind output (ie. what
> normally goes to stderr), and then for each tool that writes an output file
> (Cachegrind, Callgrind, Massif) there would be an option like --massif-file.
> In the Callgrind case it would be --callgrind-file-prefix.
Do we really want the tool name in the option? I would vote for one global
option "--output-file=..." to specify an output file name/pattern, and the tool
is free to add suffixes. This makes it easier for the user to remember
* the option name and
* the fact that this option allows for pattern specification.
I currently have the "--base=<prefix>" option in callgrind which does _not_ allow
for patterns. I will deprecate it, but should support it for some time for
backwards compatibility. I think it really would confuse the user if I additionally
provide a "--callgrind-file-prefix" which allows for patterns...
Josef
>
> Does this make sense?
>
> Nick
>
|
|
From: Nicholas N. <nj...@cs...> - 2007-11-15 04:54:54
|
On Wed, 14 Nov 2007, Josef Weidendorfer wrote:
> Can we solve this QUAL issue also via format string, e.g. via "...%{QUAL}...",
> such that %{QUAL} is replaced by Valgrind with $QUAL from the current
> environment?
Yes, Julian and I had come to the same conclusion.
> I thought a little bit about the problem with callgrind.
> IMHO I need multiple format strings for different scenarios, but
> the format strings could refer to substitution results of each other.
> E.g. it would be nice if the consistent output name specified with "--out-file=..."
> could be refered in further arbitrary format strings as the tool requires, e.g.
> as "...%o..." (for _o_utput file). Then, e.g. the default for "termination
> with separate counters per thread" would be "%o-%t".
I didn't really follow that, but it seems like Callgrind produces multiple
output files. They all have a common prefix, and then each one has a
different suffix. When it comes to processing them, presumably you give
callgrind_annotate/KCachegrind the prefix, and then they can find all the
extra files because they know what the suffixes look like.
In other words, it makes sense for a user to specify the prefix, but not the
suffix, because the processing tools depend on them having a particular
form.
If I'm right, then I think we only need:
%p process id
%q{QUAL} environment variable contents
%T for toolname isn't necessary, nor are %t or %c because they're not
controllable by the user.
Overall, we'd have a --log-file option for normal Valgrind output (ie. what
normally goes to stderr), and then for each tool that writes an output file
(Cachegrind, Callgrind, Massif) there would be an option like --massif-file.
In the Callgrind case it would be --callgrind-file-prefix.
Does this make sense?
Nick
|
|
From: Julian S. <js...@ac...> - 2007-11-15 03:54:49
|
Eyal, Konstantin, On Wednesday 14 November 2007 10:52, Konstantin Serebryany wrote: > In my case I had to go down to 14. :( > This is rather risky since we will be getting out of lock sets then. > > On Nov 12, 2007 3:41 PM, Eyal Lebedinsky <ey...@ey...> wrote: > > 15 really did it (completed one servers test now). I made an experimental version of Helgrind which fixes this. With it, up to 2^30 thread sets and 2^30 lock sets are allowed and so for all practical purposes you should never run out of either. However, the cost is a slowdown in the region 0% - 20% and approximately a 20% increase in memory consumption. J |
|
From: Tom H. <th...@cy...> - 2007-11-15 03:52:03
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-11-15 03:15: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 == 316 tests, 58 stderr failures, 1 stdout failure, 27 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/match-overrun (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/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/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-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/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) |
|
From: Tom H. <th...@cy...> - 2007-11-15 03:28:16
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-11-15 03:05: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 == 350 tests, 6 stderr failures, 2 stdout failures, 0 post failures == 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...> - 2007-11-15 03:21:25
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-11-15 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 == 352 tests, 24 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (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/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/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) |
|
From: Tom H. <th...@cy...> - 2007-11-15 03:11:07
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-11-15 03:10:03 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... failed Last 20 lines of verbose log follow echo checking dependency style of g++... gcc3 checking for ranlib... ranlib checking for perl... /usr/bin/perl checking for gdb... /usr/bin/gdb checking dependency style of gcc... gcc3 checking for a supported version of gcc... ok (gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)) checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a supported CPU... ok (x86_64) checking for use as an inner Valgrind... no checking for a 64-bit only build... no checking for a 32-bit only build... no checking for a supported OS... ok (linux-gnu) checking for the kernel version... 2.6 family (2.6.23.1-49.fc8) checking for 32 bit build support... yes checking for a supported CPU/OS combination... ok (x86_64-linux-gnu) checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking the libc version... unsupported version configure: error: Valgrind requires glibc version 2.2 - 2.6 |
|
From: <js...@ac...> - 2007-11-15 01:21:52
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-11-15 02:00:01 CET 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 == 284 tests, 25 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) 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/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (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) ================================================= == 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 == 284 tests, 25 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) 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/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Nov 15 02:10:24 2007 --- new.short Thu Nov 15 02:21:55 2007 *************** *** 8,10 **** ! == 284 tests, 25 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 284 tests, 25 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) *************** *** 25,26 **** --- 25,27 ---- helgrind/tests/tc07_hbl1 (stderr) + helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc08_hbl2 (stderr) |