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
(9) |
2
(7) |
3
(15) |
4
(14) |
|
5
(12) |
6
(18) |
7
(16) |
8
(13) |
9
(14) |
10
(20) |
11
(26) |
|
12
(14) |
13
(25) |
14
(20) |
15
(15) |
16
(14) |
17
(13) |
18
(12) |
|
19
(8) |
20
(16) |
21
(15) |
22
(37) |
23
(15) |
24
(18) |
25
(12) |
|
26
(8) |
27
(13) |
28
(12) |
|
|
|
|
|
From: Stephen M.
|
>>>>> "JS" == Julian Seward <js...@ac...> writes:
SMcC> I can't say I understand why the %fpucw check fails when you're
SMcC> self-hosting, but it seems at least plausible that a similar
SMcC> issue affects the %mxcsr check. I'm not sure what it is about
SMcC> our tool that tickles this problem; I didn't see similar
SMcC> failures with a memcheck built from a pristine valgrind source
JS> Check that the helper functions your tool calls do not mess with
JS> mxcsr. Technically it is caller saved, but saving it across all
JS> helper function calls would be expensive and so vex doesn't.
I grepped for ldmxscr in the disassembly of our statically linked tool
binary (is that a good way to check?) and found two uses: one in
vgPlain_run_innerloop(), which looks like it's setting up the value
that the failing check expects to find, and one in __setfpucw(), which
is called by glibc's init(). The latter seems likely to be part of the
problem, but it doesn't seem likely to be getting called from a helper
function. I also think I remember that the failure was happening on
the very first dispatch.
I suspect there's something subtle going on here with the multiple
levels of interpretation involved in self-hosting that I'm curious to
understand but can't put my finger on. However, if this doesn't ring
any bells with you, it'll be a while before I have the time to look
into it further, given that we already have both a workaround and a
strategy for a long-term fix.
SMcC> (our tool is based in part on
SMcC> memcheck). One potentially significant difference is that we still
SMcC> link with glibc (I get the impression that's discouraged,
JS> Very much so.
[...]
JS> I would not be surprised to find that your use of glibc causes V to
JS> bomb with an assertion failure when running large programs with the
JS> flag --sanity-level=3 or above.
Indeed it does, though we hadn't noticed this in the past, since we
don't often use the sanity checks, and we hadn't seen any other
consequences of the insanity. But I guess this does bump avoiding
glibc a bit up our priority list.
-- Stephen
|
|
From: Julian S. <js...@ac...> - 2006-02-27 18:15:07
|
> I can't say I understand why the %fpucw check fails when you're > self-hosting, but it seems at least plausible that a similar issue > affects the %mxcsr check. I'm not sure what it is about our tool that > tickles this problem; I didn't see similar failures with a memcheck > built from a pristine valgrind source Check that the helper functions your tool calls do not mess with mxcsr. Technically it is caller saved, but saving it across all helper function calls would be expensive and so vex doesn't. > (our tool is based in part on > memcheck). One potentially significant difference is that we still > link with glibc (I get the impression that's discouraged, Very much so. We too have been loathe to lose glibc support, but after a long and somewhat confusing discussion some months ago, it became clear that linking in glibc opens the possibility of various kinds of bad interactions between glibc and V, since V needs to control various kinds of resources (address space layout, signal state) but glibc believes that it is the sole owner of such resources. Getting rid of glibc was therefore a step forward from both a stability and portability standpoint. I would not be surprised to find that your use of glibc causes V to bomb with an assertion failure when running large programs with the flag --sanity-level=3 or above. J |
|
From: Yao Qi <qiy...@cn...> - 2006-02-27 10:17:52
|
On Fri, Feb 24, 2006 at 11:42:29PM +0100, Josef Weidendorfer wrote: > Hi, > > it had a short look over the code. > > So you print out all instructions where debug info says that they > are in this function, right? You decide this in the callback Yes, you are right! > function, which is run for every instruction in the code. > Why not decide this already in the instrumentation phase? At first, we did put all the instruction display in the instrumentation phase, but later, when we want to collect the information about memory access, data and address, I found that some data and address are generated at run time, so I had to put print_write_data() and print_read_data() in a callback form at run-time to collect some run-time information. I think this would decrease the efficiency of valgrind and itrace, but I could not find another better solution to it. In order to keep the order of instruction display and memory access display, that is to say, "R" or "W" record follow closedly to "I" or "J" record if this instruction access memory, I put print_instruction() into callback. Otherwise, instructions will be displayed first at instrumentation phase, and memory access will be displayed later at the run time, it would destroy the readability of the final output. If anyone here any better idea or comments to this, feel free to tell us. > > > and only record instructions in this function you specified, while the > > latter could enable itrace to record all instructions in this function > > and instructions in functions called by this function. > > I am not sure if this very simple calltree tracing is the right thing to > include into VG source. At least there should be a big warning in the > code/docu that this does not work > * with multithreaded code (switching to another thread while in the function > will leave you with tracing on) > * with signal handlers (which will be traced, too) > * with functions which are left via a jump (_dl_runtime_resolve, longjmps, > perhaps exception handling, handcrafted assembler ...) > * only with ISAs where VEX can identify RET instructions (AFAIK for PPC the > jumpkind is only a hint here as PPC has no explicit RET instructions) We did few tests on above you mentioned, so we are not sure what would happen when itrace tracing a multithreaded program, a signal handler and exception handler. We will pay attention on these aspects and update the document per the test result! > > I include a patch of valgrind-itrace in attachment, and please apply it > > to valgrind-3.1.0. > > I am not the one to decide this, but I think it probably would be nice to add > instruction tracing and function filtering (done at instrumentation time) > to lackey. We would like to have try to port the code of itrace to lackey! > > Why do you not simply provide an external tool package? You can look at > the configure.in and Makefile.am's in callgrind which does exactly this > (granted, with some problems regarding biarch support). > > Josef -- Regards, Yao ------------ Yao Qi |
|
From: <js...@ac...> - 2006-02-27 10:15:33
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-27 02:00:01 GMT 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 == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) ================================================= == 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 == 192 tests, 11 stderr failures, 6 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) none/tests/tls (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Feb 27 02:24:33 2006 --- new.short Mon Feb 27 02:43:48 2006 *************** *** 8,10 **** ! == 192 tests, 11 stderr failures, 6 stdout failures ================= memcheck/tests/leak-cycle (stderr) --- 8,10 ---- ! == 192 tests, 11 stderr failures, 5 stdout failures ================= memcheck/tests/leak-cycle (stderr) *************** *** 25,27 **** none/tests/ppc32/test_gx (stdout) - none/tests/tls (stdout) --- 25,26 ---- |
|
From: <sv...@va...> - 2006-02-27 09:34:34
|
Author: dirk Date: 2006-02-27 09:34:29 +0000 (Mon, 27 Feb 2006) New Revision: 5702 Log: dox update Modified: trunk/docs/internals/3_1_BUGSTATUS.txt Modified: trunk/docs/internals/3_1_BUGSTATUS.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-27 08:42:07 UTC (rev 5= 701) +++ trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-27 09:34:29 UTC (rev 5= 702) @@ -55,6 +55,7 @@ pending pending n-i-bz XML output truncated (users, Jan 26 09:08:3= 4 2006) pending pending 121896 Handling ESP modification in ucontext from = signal handlers v5651 v5679 121901 no support for syscall tkill +v5700 v5701 n-i-bz Suppression update for Debian unstable =20 (next 3 are ppc32-specific FP problems) many v5694/5 n-i-bz ppc32 rounding mode problems |
|
From: <sv...@va...> - 2006-02-27 08:42:11
|
Author: dirk
Date: 2006-02-27 08:42:07 +0000 (Mon, 27 Feb 2006)
New Revision: 5701
Log:
update suppression for ubuntu (backport v5700)
Modified:
branches/VALGRIND_3_1_BRANCH/glibc-2.3.supp
Modified: branches/VALGRIND_3_1_BRANCH/glibc-2.3.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/VALGRIND_3_1_BRANCH/glibc-2.3.supp 2006-02-27 08:41:32 UTC (=
rev 5700)
+++ branches/VALGRIND_3_1_BRANCH/glibc-2.3.supp 2006-02-27 08:42:07 UTC (=
rev 5701)
@@ -576,10 +576,10 @@
{
Ubuntu-stripped-ld.so
Memcheck:Cond
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
}
=20
|
|
From: <sv...@va...> - 2006-02-27 08:41:39
|
Author: dirk
Date: 2006-02-27 08:41:32 +0000 (Mon, 27 Feb 2006)
New Revision: 5700
Log:
update ubuntu suppression (based on patch by David Kimdon)
Modified:
trunk/glibc-2.3.supp
Modified: trunk/glibc-2.3.supp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/glibc-2.3.supp 2006-02-25 04:50:26 UTC (rev 5699)
+++ trunk/glibc-2.3.supp 2006-02-27 08:41:32 UTC (rev 5700)
@@ -576,10 +576,10 @@
{
Ubuntu-stripped-ld.so
Memcheck:Cond
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
- obj:/lib/ld-2.3.5.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
+ obj:/lib/ld-2.3.*.so
}
=20
|
|
From: <js...@ac...> - 2006-02-27 04:01:55
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-27 03:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 223 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <to...@co...> - 2006-02-27 03:44:27
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-27 03:30: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 == 225 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-27 03:31:47
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-27 03:15: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 == 224 tests, 21 stderr failures, 1 stdout failure ================= 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-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (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/sse1_memory (stdout) memcheck/tests/xml1 (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-27 03:25:48
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-27 03:10:13 GMT 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 == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (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 == 245 tests, 5 stderr failures, 2 stdout failures ================= memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/pth_cvsimple (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Feb 27 03:18:44 2006 --- new.short Mon Feb 27 03:25:37 2006 *************** *** 8,10 **** ! == 245 tests, 5 stderr failures, 2 stdout failures ================= memcheck/tests/x86/scalar (stderr) --- 8,11 ---- ! == 245 tests, 6 stderr failures, 1 stdout failure ================= ! memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) *************** *** 13,15 **** none/tests/amd64/faultstatus (stderr) - none/tests/pth_cvsimple (stdout) none/tests/x86/faultstatus (stderr) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2006-02-27 03:22:00
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-27 03:00:04 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 == 245 tests, 7 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-27 03:21:35
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-27 03:05:11 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 == 245 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/sse1_memory (stdout) none/tests/amd64/faultstatus (stderr) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) |