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
(8) |
2
(10) |
3
(18) |
4
(14) |
5
(16) |
6
(11) |
7
(10) |
|
8
(7) |
9
(8) |
10
(6) |
11
(6) |
12
(9) |
13
(13) |
14
(8) |
|
15
(3) |
16
(6) |
17
(8) |
18
(7) |
19
(7) |
20
(7) |
21
(5) |
|
22
(6) |
23
(5) |
24
(5) |
25
(5) |
26
(7) |
27
(7) |
28
(7) |
|
29
(15) |
30
(11) |
|
|
|
|
|
|
From: Michael A. <Mic...@fs...> - 2007-04-06 16:45:26
|
Julian Seward wrote: > >> I would disagree because those instructions will be used on supported >> CPUs. They would be limited to Intel Core 2 CPUs at the moment (and >> potentially some of the high end Opterons), but they are legal >> instructions and valgrind should handle them properly. > > I agree. Like I said, if one of you would file a report in our bug > tracker that would help. Don't bother with a test program; just say > that lahf and sahf do not currently work in 64-bit mode. > Done. >> Does AMD64 cover also cover EMT64 by Intel? > > Yes. Works fine on my E6600. > Great, thanks. > J > Cheers, Michael |
|
From: Julian S. <js...@ac...> - 2007-04-06 16:24:01
|
> I would disagree because those instructions will be used on supported > CPUs. They would be limited to Intel Core 2 CPUs at the moment (and > potentially some of the high end Opterons), but they are legal > instructions and valgrind should handle them properly. I agree. Like I said, if one of you would file a report in our bug tracker that would help. Don't bother with a test program; just say that lahf and sahf do not currently work in 64-bit mode. > Does AMD64 cover also cover EMT64 by Intel? Yes. Works fine on my E6600. J |
|
From: Michael A. <Mic...@fs...> - 2007-04-06 16:07:49
|
Jason Martin wrote: > Hi Michael, > Hello Jason, hello folks, > Thanks for the bug report! > > That is indeed lahf/sahf which I do use in my assembly code. Note > that the lahf/sahf instruction is not supported on some x86_64 CPUs. > However, it IS supported on the Intel Core 2 CPUs. (Please note that > the Intel "Core Duo" is not the same as the Intel "Core 2 Duo." > Despite the similarity in the names of the processors, they have very > different architectures.) > Ok. > I'm not familiar with Valgrind, but I just looked it up and it appears > to be a nice debugging package. My guess is that since lahf/sahf is > not supported on Pentium4 and early Xeon processors, the Valgrind > package is trapping for lahf/sahf and flagging it as an unsupported > instruction even on processors where it is allowed. This seems like > good practice to me because it ensures that the resulting binary will > be more portable. So, I would not consider this a bug in Valgrind. > I would disagree because those instructions will be used on supported CPUs. They would be limited to Intel Core 2 CPUs at the moment (and potentially some of the high end Opterons), but they are legal instructions and valgrind should handle them properly. If you use SSE3 on an older pentium you will get failures, but that's not valgrind's fault. > I chose the lahf/sahf pair to save and restore the Carry Flag because > on the Core 2 architecture lahf/sahf can execute without stalling the > execution pipeline... (other common methods of saving and restoring > the CF state such as conditional moves, bit tests, and the add with > carry instructions can create a false dependency with surrounding > arithmetic instructions which adds latency to a critical loop). > > I hadn't realized that this would be a problem, but now that you've > encountered it I'm re-thinking my design decision. I think I will go > back and re-write that section of code so that by default it will > produce a slower-but-more-portable instruction and then give users the > option of compiling with the faster lahf/sahf if they want it. > Ok, I would always prefer performance over portability since the gmp has code for "lesser" CPUs. > Thanks, > jason > > On 4/6/07, Julian Seward <js...@ac...> wrote: >> >> > vex amd64->IR: unhandled instruction bytes: 0x9F 0x49 0x89 0xC9 >> >> That looks like lahf/sahf. Maybe you can configure GMP not to use >> those? >> In the meantime please file a bug report as described at >> http://www.valgrind.org/support/bug_reports.html >> so this can be tracked properly. >> >> J >> Great, I would suggest that Jason should write a short assembly program. I am willing to do it, but the last time I did assembly programming was in the hey days of 68k, so I am a little rusty there. I can take the code from him and run valgrind on it and file the bug report then in case Jason doesn't have time for it. One more thing: When I run configure for 3.3.0SVN on this box processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz stepping : 6 cpu MHz : 1596.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 4789.13 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: I get Primary build target: AMD64_LINUX Secondary build target: X86_LINUX Default supp files: xfree-3.supp xfree-4.supp glibc-2.5.supp Does AMD64 cover also cover EMT64 by Intel? Cheers, Michael |
|
From: Julian S. <js...@ac...> - 2007-04-06 13:01:04
|
> vex amd64->IR: unhandled instruction bytes: 0x9F 0x49 0x89 0xC9 That looks like lahf/sahf. Maybe you can configure GMP not to use those? In the meantime please file a bug report as described at http://www.valgrind.org/support/bug_reports.html so this can be tracked properly. J |
|
From: <js...@ac...> - 2007-04-06 11:47:31
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-04-06 09:00:01 BST 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 == 219 tests, 10 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) none/tests/pth_detached (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 == 219 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Apr 6 09:13:53 2007 --- new.short Fri Apr 6 09:26:58 2007 *************** *** 8,10 **** ! == 219 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) --- 8,10 ---- ! == 219 tests, 10 stderr failures, 7 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) *************** *** 25,26 **** --- 25,27 ---- none/tests/ppc32/test_gx (stdout) + none/tests/pth_detached (stdout) |
|
From: Michael A. <Mic...@fs...> - 2007-04-06 08:43:16
|
Hello folks, hello Martin, hello Jason, before I get to my problem let me thank you for a excellent piece of software. Valgrind has saved me lots of time over and over again. I would consider it the most important piece of debugging tools in my arsenal. I just got the following problem when valgrinding a gmp-4.2.1 with Jason Martin's CoreDuo patch with the 3.2.3 release: vex amd64->IR: unhandled instruction bytes: 0x9F 0x49 0x89 0xC9 After checking out current SVN (3.3.0SVN according to --version) from today I reran the test and I still got the same problem. I couldn't find anything useful in the archives. Because Jason's Core Duo patch uses hand crafted assembly code to speed up the gmp for CoreDuos and the standard gmp has no such problems I cc'ed him as well as Martin since he pointed out that problem to me yesterday in private conversation. To reproduce: Get a gmp-4.2.1, get Jason Martin's CoreDuo patch from http://www.math.jmu.edu/~martin/gmp-4.2.1-core2-port.tar.gz Apply that patch on a CoreDuo and build the gmp, make check so that all the tests are run an build. Then use memcheck on t-sub (which is somewhere in the test directory after "make check". Let me know if I can help you any other way or if I got this all completely wrong and it is my fault ;) Cheers, Michael The complete output was: /tmp/Work/gmp-test>/tmp/Work/valgrind-20070406-svn/bin/valgrind --tool=memcheck --leak-resolution=high --show-reachable=yes ./t-sub ==15593== Memcheck, a memory error detector. ==15593== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==15593== Using LibVEX rev 1748, a library for dynamic binary translation. ==15593== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==15593== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==15593== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==15593== For more details, rerun with: -v ==15593== vex amd64->IR: unhandled instruction bytes: 0x9F 0x49 0x89 0xC9 ==15593== valgrind: Unrecognised instruction at address 0x40E135. ==15593== Your program just tried to execute an instruction that Valgrind ==15593== did not recognise. There are two possible reasons for this. ==15593== 1. Your program has a bug and erroneously jumped to a non-code ==15593== location. If you are running Memcheck and you just saw a ==15593== warning about a bad jump, it's probably your program's fault. ==15593== 2. The instruction is legitimate but Valgrind doesn't handle it, ==15593== i.e. it's Valgrind's fault. If you think this is the case or ==15593== you are not sure, please let us know and we'll try to fix it. ==15593== Either way, Valgrind will now raise a SIGILL signal which will ==15593== probably kill your program. ==15593== ==15593== Process terminating with default action of signal 4 (SIGILL) ==15593== Illegal opcode at address 0x40E135 ==15593== at 0x40E135: __gmpn_add_n (in /tmp/Work/gmp-test/t-sub) ==15593== by 0x40A40D: __gmpf_sub (in /tmp/Work/gmp-test/t-sub) ==15593== by 0x4014E3: check_rand (in /tmp/Work/gmp-test/t-sub) ==15593== by 0x401728: main (in /tmp/Work/gmp-test/t-sub) ==15593== ==15593== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1) ==15593== malloc/free: in use at exit: 2,916 bytes in 16 blocks. ==15593== malloc/free: 18 allocs, 2 frees, 2,964 bytes allocated. ==15593== For counts of detected errors, rerun with: -v ==15593== searching for pointers to 16 not-freed blocks. ==15593== checked 79,872 bytes. ==15593== ==15593== LEAK SUMMARY: ==15593== definitely lost: 0 bytes in 0 blocks. ==15593== possibly lost: 0 bytes in 0 blocks. ==15593== still reachable: 2,916 bytes in 16 blocks. ==15593== suppressed: 0 bytes in 0 blocks. ==15593== Rerun with --leak-check=full to see details of leaked memory. Illegal instruction |
|
From: Tom H. <th...@cy...> - 2007-04-06 03:14:22
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-04-06 03:00:02 BST 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 == 293 tests, 6 stderr failures, 2 stdout failures, 0 posttest 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) none/tests/tls (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 == 293 tests, 6 stderr failures, 3 stdout failures, 0 posttest 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) none/tests/pth_detached (stdout) none/tests/tls (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Apr 6 03:35:31 2007 --- new.short Fri Apr 6 04:11:28 2007 *************** *** 8,10 **** ! == 293 tests, 6 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 293 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 16,18 **** none/tests/mremap2 (stdout) - none/tests/pth_detached (stdout) none/tests/tls (stdout) --- 16,17 ---- |
|
From: Tom H. <th...@cy...> - 2007-04-06 02:32:00
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-04-06 03:15:02 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 == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest 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) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-04-06 02:23:39
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2007-04-06 03:10:04 BST 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 == 291 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (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 == 291 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Apr 6 03:16:57 2007 --- new.short Fri Apr 6 03:23:31 2007 *************** *** 8,10 **** ! == 291 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 291 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 14,16 **** none/tests/mremap2 (stdout) - none/tests/pth_cvsimple (stdout) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2007-04-06 02:19:14
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-04-06 03:05:07 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 == 291 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-04-06 00:16:26
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-04-06 02:00:01 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 == 226 tests, 6 stderr failures, 2 stdout failures, 0 posttest 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) |