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: Bryan M. <om...@br...> - 2006-02-21 23:39:54
|
Dear Valgrind Developers List, for those interested, you can find a patch against svn here: http://www.brainmurders.eclipse.co.uk/omega_ALPHA_04.patch.gz This is _ALPHA_ software and if it eats your system, you get to keep whatever it spits out. There are still problems: Ignore the docs - they need an update from early dreams to reality. (Why do so many libraries access memory inside of blocks that they have called free() on? *sighs*) Note that this patches VEX in order to sort out an issue I have with popping values off the stack. Only tested on x86 so far but amd64 shouldn't be too bad. Sometimes doesn't report a leak when you think it should - because I have to track pointers in registers, we can't leak until the registers are changed to something else. This is more of a problem with trivial programs. For best results, compile your program to be tested with -O0 -g and make sure that valgrind complains about nothing but memory leaks... You might want to pipe the output into a file as there can be rather a lot of it. Any and all comments are very welcome. Thanks for the help so far. Bryan "Brain Murders" Meredith |
|
From: Nicholas N. <nj...@cs...> - 2006-02-21 22:18:30
|
On Tue, 21 Feb 2006, David Kimdon wrote: > If there aren't any real vex related changes in COMPVBITS then we > never have to merge the vex valgrind/trunk changes into COMPVBITS. > We will just merge COMPVBITS back into trunk when it is done. Yes. COMPVBITS is now ready for the trunk. I might get to merging it in the next week, if not then I won't have time until the end of March. Either way it should make it into 3.2.0. > In that case perhaps we can decide on which version of VEX the > COMPVBITS branch will use, and add that to the externals property so > it gets pulled in automatically? > > Something like the following will lock VEX to the revision that Julian > found works (it builds for me as well): > > Property changes on: > ___________________________________________________________________ > Name: svn:externals > - VEX svn://svn.valgrind.org/vex/trunk > > + VEX -r1535 svn://svn.valgrind.org/vex/trunk That would be fine by me. N |
|
From: David K. <dw...@de...> - 2006-02-21 21:42:05
|
On 2/19/06, Julian Seward <js...@ac...> wrote: > Yeh, I was trying to shake out a 64-bit bug just now and also had > difficulties on checkout. Eventually I did this: ok, thanks, that builds for me. If there aren't any real vex related changes in COMPVBITS then we never have to merge the vex valgrind/trunk changes into COMPVBITS. We will just merge COMPVBITS back into trunk when it is done. In that case perhaps we can decide on which version of VEX the COMPVBITS branch will use, and add that to the externals property so it gets pulled in automatically? Something like the following will lock VEX to the revision that Julian found works (it builds for me as well): Property changes on: ___________________________________________________________________ Name: svn:externals - VEX svn://svn.valgrind.org/vex/trunk + VEX -r1535 svn://svn.valgrind.org/vex/trunk |
|
From: <sv...@va...> - 2006-02-21 18:04:20
|
Author: dirk
Date: 2006-02-21 18:04:16 +0000 (Tue, 21 Feb 2006)
New Revision: 5664
Log:
update suppression
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-21 18:04:04 UTC (rev 5663)
+++ trunk/glibc-2.3.supp 2006-02-21 18:04:16 UTC (rev 5664)
@@ -419,39 +419,38 @@
=20
=20
##----------------------------------------------------------------------=
##
-## glibc-2.3.5 on SuSE 10.0 (PPC)
#=20
# I don't know why this is needed, but still:
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-1
+ glibc-2.3.x-on-SuSE-10.0/10.1-(PPC)-1
Memcheck:Cond
fun:_dl_start
fun:_start
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-2a
+ glibc-2.3.x-on-SuSE-10.0/10.1-(PPC)-2a
Memcheck:Cond
fun:index
- obj:*ld-2.3.5.so
+ obj:*ld-2.3.*.so
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-2b
+ glibc-2.3.x-on-SuSE-10.0/10.1-(PPC)-2b
Memcheck:Addr4
fun:index
fun:expand_dynamic_string_token
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-2c
+ glibc-2.3.5-on-SuSE-10.0/10.1-(PPC)-2c
Memcheck:Addr4
fun:index
- obj:*ld-2.3.5.so
+ obj:*ld-2.3.*.so
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-3
+ glibc-2.3.5-on-SuSE-10.0/10.1-(PPC)-3
Memcheck:Addr4
fun:*wordcopy_fwd_dest_aligned*
fun:mem*cpy
- obj:*lib*2.3.5.so
+ obj:*lib*2.3.*.so
}
=20
=20
|
|
From: <sv...@va...> - 2006-02-21 18:04:10
|
Author: dirk
Date: 2006-02-21 18:04:04 +0000 (Tue, 21 Feb 2006)
New Revision: 5663
Log:
update suppression
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-21 17:11:11 UTC (=
rev 5662)
+++ branches/VALGRIND_3_1_BRANCH/glibc-2.3.supp 2006-02-21 18:04:04 UTC (=
rev 5663)
@@ -419,39 +419,38 @@
=20
=20
##----------------------------------------------------------------------=
##
-## glibc-2.3.5 on SuSE 10.0 (PPC)
#=20
# I don't know why this is needed, but still:
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-1
+ glibc-2.3.x-on-SuSE-10.0/10.1-(PPC)-1
Memcheck:Cond
fun:_dl_start
fun:_start
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-2a
+ glibc-2.3.x-on-SuSE-10.0/10.1-(PPC)-2a
Memcheck:Cond
fun:index
- obj:*ld-2.3.5.so
+ obj:*ld-2.3.*.so
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-2b
+ glibc-2.3.x-on-SuSE-10.0/10.1-(PPC)-2b
Memcheck:Addr4
fun:index
fun:expand_dynamic_string_token
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-2c
+ glibc-2.3.5-on-SuSE-10.0/10.1-(PPC)-2c
Memcheck:Addr4
fun:index
- obj:*ld-2.3.5.so
+ obj:*ld-2.3.*.so
}
{
- glibc-2.3.5-on-SuSE-10.0-(PPC)-3
+ glibc-2.3.5-on-SuSE-10.0/10.1-(PPC)-3
Memcheck:Addr4
fun:*wordcopy_fwd_dest_aligned*
fun:mem*cpy
- obj:*lib*2.3.5.so
+ obj:*lib*2.3.*.so
}
=20
=20
|
|
From: <sv...@va...> - 2006-02-21 17:43:26
|
Author: sewardj
Date: 2006-02-21 17:43:20 +0000 (Tue, 21 Feb 2006)
New Revision: 1575
Log:
Re-enable 'fsqrt'. This isn't really correct in the sense that the
insn is allowed even if the CPU doesn't support it. No matter; it
is done properly in the svn trunk (to become 3.2.0).
Modified:
branches/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c
Modified: branches/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c
=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/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c 2006-02-09 02:54:03 U=
TC (rev 1574)
+++ branches/VEX_3_1_BRANCH/priv/guest-ppc32/toIR.c 2006-02-21 17:43:20 U=
TC (rev 1575)
@@ -4419,15 +4419,15 @@
assign( frD, binop( Iop_AddF64, mkexpr(frA), mkexpr(frB) ) );
break;
=20
-//zz case 0x16: // fsqrt (Floating SqRt (Double-Precision), PPC32 =
p427)
-//zz if (frA_addr !=3D 0 || frC_addr !=3D 0) {
-//zz vex_printf("dis_fp_arith(PPC32)(instr,fsqrt)\n");
-//zz return False;
-//zz }
-//zz DIP("fsqrt%s fr%d,fr%d\n", flag_rC ? "." : "",
-//zz frD_addr, frB_addr);
-//zz assign( frD, unop( Iop_SqrtF64, mkexpr(frB) ) );
-//zz break;
+ case 0x16: // fsqrt (Floating SqRt (Double-Precision), PPC32 p427)
+ if (frA_addr !=3D 0 || frC_addr !=3D 0) {
+ vex_printf("dis_fp_arith(PPC32)(instr,fsqrt)\n");
+ return False;
+ }
+ DIP("fsqrt%s fr%d,fr%d\n", flag_rC ? "." : "",
+ frD_addr, frB_addr);
+ assign( frD, unop( Iop_SqrtF64, mkexpr(frB) ) );
+ break;
=20
case 0x17: { // fsel (Floating Select, PPC32 p426)
IRTemp cc =3D newTemp(Ity_I32);
|
|
From: <sv...@va...> - 2006-02-21 17:11:20
|
Author: sewardj
Date: 2006-02-21 17:11:11 +0000 (Tue, 21 Feb 2006)
New Revision: 5662
Log:
Fix CPU feature identification for ppc32/64 - add more paranoia, and=20
configure the sigill handler so that it can be used more than once.
Modified:
trunk/coregrind/m_machine.c
Modified: trunk/coregrind/m_machine.c
=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/coregrind/m_machine.c 2006-02-20 20:57:33 UTC (rev 5661)
+++ trunk/coregrind/m_machine.c 2006-02-21 17:11:11 UTC (rev 5662)
@@ -342,22 +342,30 @@
struct vki_sigaction saved_act, tmp_act;
=20
volatile Bool have_F, have_V, have_FX, have_GX;
+ Int r;
=20
VG_(sigemptyset)(&tmp_set);
VG_(sigaddset)(&tmp_set, VKI_SIGILL);
=20
- VG_(sigprocmask)(VKI_SIG_UNBLOCK, &tmp_set, &saved_set);
+ r =3D VG_(sigprocmask)(VKI_SIG_UNBLOCK, &tmp_set, &saved_set);
+ vg_assert(r =3D=3D 0);
=20
- VG_(sigaction)(VKI_SIGILL, NULL, &saved_act);
+ r =3D VG_(sigaction)(VKI_SIGILL, NULL, &saved_act);
+ vg_assert(r =3D=3D 0);
tmp_act =3D saved_act;
=20
+ /* NODEFER: signal handler does not return (from the kernel's point=
of
+ view), hence if it is to successfully catch a signal more than o=
nce,
+ we need the NODEFER flag. */
tmp_act.sa_flags &=3D ~VKI_SA_RESETHAND;
tmp_act.sa_flags &=3D ~VKI_SA_SIGINFO;
+ tmp_act.sa_flags |=3D VKI_SA_NODEFER;
=20
/* standard FP insns */
have_F =3D True;
tmp_act.ksa_handler =3D handler_sigill;
- VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ r =3D VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ vg_assert(r =3D=3D 0);
if (__builtin_setjmp(env_sigill)) {
have_F =3D False;
} else {
@@ -367,7 +375,8 @@
/* Altivec insns */
have_V =3D True;
tmp_act.ksa_handler =3D handler_sigill;
- VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ r =3D VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ vg_assert(r =3D=3D 0);
if (__builtin_setjmp(env_sigill)) {
have_V =3D False;
} else {
@@ -377,7 +386,8 @@
/* General-Purpose optional (fsqrt, fsqrts) */
have_FX =3D True;
tmp_act.ksa_handler =3D handler_sigill;
- VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ r =3D VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ vg_assert(r =3D=3D 0);
if (__builtin_setjmp(env_sigill)) {
have_FX =3D False;
} else {
@@ -387,15 +397,18 @@
/* Graphics optional (stfiwx, fres, frsqrte, fsel) */
have_GX =3D True;
tmp_act.ksa_handler =3D handler_sigill;
- VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ r =3D VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
+ vg_assert(r =3D=3D 0);
if (__builtin_setjmp(env_sigill)) {
have_GX =3D False;
} else {
__asm__ __volatile__("frsqrte 0,0");
}
=20
- VG_(sigaction)(VKI_SIGILL, &saved_act, NULL);
- VG_(sigprocmask)(VKI_SIG_SETMASK, &saved_set, NULL);
+ r =3D VG_(sigaction)(VKI_SIGILL, &saved_act, NULL);
+ vg_assert(r =3D=3D 0);
+ r =3D VG_(sigprocmask)(VKI_SIG_SETMASK, &saved_set, NULL);
+ vg_assert(r =3D=3D 0);
/*
VG_(printf)("F %d V %d FX %d GX %d\n",=20
(Int)have_F, (Int)have_V, (Int)have_FX, (Int)have_GX=
);
@@ -439,8 +452,12 @@
VG_(sigaction)(VKI_SIGILL, NULL, &saved_act);
tmp_act =3D saved_act;
=20
+ /* NODEFER: signal handler does not return (from the kernel's point=
of
+ view), hence if it is to successfully catch a signal more than o=
nce,
+ we need the NODEFER flag. */
tmp_act.sa_flags &=3D ~VKI_SA_RESETHAND;
tmp_act.sa_flags &=3D ~VKI_SA_SIGINFO;
+ tmp_act.sa_flags |=3D VKI_SA_NODEFER;
=20
/* standard FP insns */
have_F =3D True;
|
|
From: <js...@ac...> - 2006-02-21 09:26:10
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-21 02:00: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 == 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) |
|
From: <js...@ac...> - 2006-02-21 03:57:54
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-02-21 04:40:00 CET 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 == 197 tests, 6 stderr failures, 1 stdout failure ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) |
|
From: Julian S. <js...@ac...> - 2006-02-21 03:46:37
|
> If we do 3.1.1 I'm thinking it would be nice to have it available before > FOSDEM, which probably means early next week. To follow up on that .. there's no way that's going to happen before Fosdem now. I'm suggesting that Friday 3 March is a more realistic date. Also, I'd like to suggest a mid-April date for 3.2.0, which is shaping up nicely. J |
|
From: Tom H. <to...@co...> - 2006-02-21 03:43:59
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-21 03:30: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 == 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-21 03:32:32
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-21 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 == 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-21 03:30:31
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-21 03:15: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 == 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-21 03:24:29
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-21 03:10:06 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, 5 stderr failures, 1 stdout failure ================= 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, 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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Feb 21 03:18:03 2006 --- new.short Tue Feb 21 03:24:22 2006 *************** *** 8,11 **** ! == 245 tests, 6 stderr failures, 1 stdout failure ================= ! memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) --- 8,10 ---- ! == 245 tests, 5 stderr failures, 1 stdout failure ================= memcheck/tests/x86/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2006-02-21 03:20:47
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-21 03:05:12 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) |