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: <sv...@va...> - 2006-02-14 21:55:16
|
Author: sewardj Date: 2006-02-14 21:55:11 +0000 (Tue, 14 Feb 2006) New Revision: 5650 Log: Apparently on SLES9 the dynamic linker is called (soname'd) ld64.so.1. Add a corresponding strcmp redirect. Modified: trunk/memcheck/mac_replace_strmem.c Modified: trunk/memcheck/mac_replace_strmem.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/memcheck/mac_replace_strmem.c 2006-02-14 21:48:42 UTC (rev 5649= ) +++ trunk/memcheck/mac_replace_strmem.c 2006-02-14 21:55:11 UTC (rev 5650= ) @@ -120,6 +120,7 @@ #define m_libc_so_star libcZdsoZa // libc.so* #define m_ld_linux_so_2 ldZhlinuxZdsoZd2 // ld-linux.= so.2 #define m_ld_linux_x86_64_so_2 ldZhlinuxZhx86Zh64ZdsoZd2 // ld-linux-= x86-64.so.2 +#define m_ld64_so_1 ld64ZdsoZd1 // ld64.so.1 =20 =20 #define STRRCHR(soname, fnname) \ @@ -338,6 +339,7 @@ =20 STRCMP(m_libc_so_star, strcmp) STRCMP(m_ld_linux_x86_64_so_2, strcmp) +STRCMP(m_ld64_so_1, strcmp) =20 =20 #define MEMCHR(soname, fnname) \ |
|
From: <sv...@va...> - 2006-02-14 21:48:55
|
Author: sewardj
Date: 2006-02-14 21:48:42 +0000 (Tue, 14 Feb 2006)
New Revision: 5649
Log:
A few more syscalls.
Modified:
trunk/coregrind/m_syswrap/syswrap-ppc64-linux.c
Modified: trunk/coregrind/m_syswrap/syswrap-ppc64-linux.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_syswrap/syswrap-ppc64-linux.c 2006-02-14 16:15:57 U=
TC (rev 5648)
+++ trunk/coregrind/m_syswrap/syswrap-ppc64-linux.c 2006-02-14 21:48:42 U=
TC (rev 5649)
@@ -1187,7 +1187,7 @@
GENX_(__NR_unlink, sys_unlink), // 10
GENX_(__NR_execve, sys_execve), // 11
GENX_(__NR_chdir, sys_chdir), // 12
-// _____(__NR_time, sys_time), // 13
+ GENXY(__NR_time, sys_time), // 13
// _____(__NR_mknod, sys_mknod), // 14
=20
GENX_(__NR_chmod, sys_chmod), // 15
@@ -1290,7 +1290,7 @@
// _____(__NR_getpriority, sys_getpriority), // 96
// _____(__NR_setpriority, sys_setpriority), // 97
// _____(__NR_profil, sys_profil), // 98
-// _____(__NR_statfs, sys_statfs), // 99
+ GENXY(__NR_statfs, sys_statfs), // 99
=20
// _____(__NR_fstatfs, sys_fstatfs), // 100
// _____(__NR_ioperm, sys_ioperm), // 101
@@ -1341,7 +1341,7 @@
// _____(__NR_setfsgid, sys_setfsgid), // 139
=20
LINXY(__NR__llseek, sys_llseek), // 140
-// _____(__NR_getdents, sys_getdents), // 141
+ GENXY(__NR_getdents, sys_getdents), // 141
// _____(__NR__newselect, sys__newselect), // 142
// _____(__NR_flock, sys_flock), // 143
// _____(__NR_msync, sys_msync), // 144
|
|
From: Eric P. <eri...@wa...> - 2006-02-14 20:44:32
|
> Well that's the point... The path for a normal signal that originates > from the kernel is like this: > > - signal delivered to sync_signalhandler or async_signalhandler > - at this point we have a ucontext with a trapno in it > > - signal passed to deliver_signal > - here the ucontext is lost as it is not passed in > > - push_signal_frame called to construct frame for client program > > - platform specific VG_(sigframe_create) called to construct frame > > - build_rt_sigframe or build_sigframe called > > - synth_ucontext called > - here we need to store the trap number in the created ucontext > > What you proposed is that synth_ucontext should try and guess the > trap number from the signal number and code. > > I am suggesting that the original kernel ucontext should be propagated > down through that call stack so that synth_ucontext can take the > original kernel supplied trap number from it which is guaranteed to > be accurate. > The only problem is that deliver_signal is called from other places > like synth_fault_common, synth_sigill and synth_sigtrap which would > have to invent a ucontext with an appropriate trap number or something. that'd be better A+ -- Eric Pouech |
|
From: <sv...@va...> - 2006-02-14 16:16:07
|
Author: sewardj
Date: 2006-02-14 16:15:57 +0000 (Tue, 14 Feb 2006)
New Revision: 5648
Log:
Trawled v-users/bugzilla-mail and added entries.
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-14 11:37:41 UTC (rev 5=
647)
+++ trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-14 16:15:57 UTC (rev 5=
648)
@@ -2,12 +2,13 @@
n-i-bz =3D not in bugzilla
pending =3D is scheduled to be fixed (or at least considered) on this br=
anch
wontfix =3D will not fix on this branch
+many =3D fix composed of many commits
=20
-
TRUNK 31BRANCH BUG# WHAT
=20
v5262 v5446 n-i-bz fsub 3,3,3 in ppc32 dispatcher doesn't clea=
r NaNs
v5270 v5447 n-i-bz ppc32: __NR_{set,get}priority
+v5384 wontfix 117096 Weird errors when --log-fd=3D has invalid v=
alue
v5470 v5479 117332 missing line info with icc 8.1 (x86)
pending pending 117362 partially defined equality
pending pending 117366 amd64: 0xDD 0x7C fnstsw
@@ -17,11 +18,14 @@
vx1492 vx1515 117419 ppc32: fsqrt (TODO: VERIFY 31BRA=
NCH)
pending wontfix n-i-bz ppc32: jm-insns doesn't do FP tests
pending wontfix 117564 __NR_clone param test (w/ partial patch)
-pending pending 117936 yet another stabs-reader segfault
+v5514 pending 117936 more stabs problems
+ =3D=3D119914
+ =3D=3D120345
pending pending 118118 SIGBUS in disInstr_AMD64 after long run
pending pending 118239 amd64: 0xF 0xAE 0x3F (clflush)
pending pending 118274 amd64: 0xDD #7 (fnsave)
pending pending 118466 add %r,%r mishandled by memcheck
+v5635 pending 118939 vm86old system call
pending pending n-i-bz VALGRIND_COUNT_LEAKS arg types (Olly Betts)
v5429 v5450 n-i-bz memcheck/tests/mempool reads freed memory
v5366/67/70 v5480 n-i-bz AshleyP's custom-allocator assertion
@@ -29,34 +33,46 @@
v5368 v5448 n-i-bz More space for debugger cmd line (Dan Thale=
r)
v5378/80 v5379/81 n-i-bz Clarified leak checker output message
v5382 v5481 n-i-bz AshleyP's --gen-suppressions output fix
-v5384 wontfix 117096 Weird errors when --log-fd=3D has invalid v=
alue
v5396 v5449 n-i-bz cg_annotate's --sort option broken=20
(TODO: VERIFY 31BRANCH)
v5427 v5451 n-i-bz OSet 64-bit fastcmp bug
v5445 pending n-i-bz VG_(getgroups) fix (Shinichi Noda)
vx1519 pending n-i-bz ppc32/64: allocate from callee-saved FP/VMX=
regs
+v5500 pending n-i-bz misaligned path word-size bug in mc_main.c
vx1521/2 pending 119297 Incorrect error message for sse code
-v5500 pending n-i-bz misaligned path word-size bug in mc_main.c
-v5514 pending 117936 more stabs problems
- 119914
- 120345
+pending pending 120410 x86: prefetchw (0xF 0xD 0x48 0x4)
v5633 pending 120728 TIOCSERGETLSR, TIOCGICOUNT, HDIO_GET_DMA io=
ctls
-v5635 pending 118939 vm86old system call
vx1419 pending 120658 Build fixes for gcc 2.96
v5593 pending 120658 Pass -Wdeclaration-after-statement to VEX b=
uild
+v5616 pending n-i-bz memcheck/tests/zeropage de-looping fix
+vx1569 pending n-i-bz x86 fxtract doesn't work reliably
+probably-wontfix 121029 std::pow returns different float values
+pending pending 121617 Assertion 'sizeof(*regs) =3D=3D sizeof(prs-=
>pr_reg)
+pending pending 121662 x86: lock xadd (0xF0 0xF 0xC0 0x2)
+v5647 pending 121893 calloc does not always zero memory
+pending pending n-i-bz XML output truncated (users, Jan 26 09:08:3=
4 2006)
=20
-119482: mtfsb1 ppc instruction not implemented
- fixed (head?) (vx1531, check)
+(next 3 are ppc32-specific FP problems)
+many pending n-i-bz ppc32 rounding mode problems
+ Is fixed properly in head
+ For 31BRANCH copy in r5591 kludge
+many wontfix 119482 ppc32: mtfsb1
+ [skip for 3.1.1 unless gcc/glibc requires i=
t]
+many wontfix 120277 ppc32: fres, fctid, fctidz, frsqrte=20
+ [skip for 3.1.1 unless gcc/glibc requires i=
t]
=20
-119973 Sun JVM problems
+v5629 pending n-i-bz Dave Nomura extra suppression
=20
-120277 unimplemented PPC floating point instructions: fres, fctid,
- fctidz, frsqrte
+pending pending 119973 Sun JVM problems (possible sigcontext probl=
em?)
+ =3D=3D118239
=20
-v5647 pending 121893 calloc does not always zero memory
+don't forget:
+Control-Z bug (Control-Z is ignored)
=20
+Possibly just close:
+ 119404 executing ssh from inside valgrind fails
=20
-don't forget:
-Dave Nomura extra suppression (dev, Tue Jan 17 00:14:30 2006)
-Control-Z bug
-Sun JVM hangs; possible sigcontext problem
+----
+last trawled 14 Feb 06:
+ bug-mail: Looked at everything up to and including 12 Feb 06.
+ v-userss: Looked at everything up to and including 14 Feb 06.
|
|
From: John R.
|
Julian Seward wrote: >>Is there a set of standard test scenarios that you've run Valgrind under >> other than the regression test suite? > > > The only other one used is to run the test suite for the GNU Scientific > Library v 1.6 on Valgrind. http://www.gnu.org/software/gsl. ... The internal testsuite for glibc C runtime library can be adapted. Nearly all the tests (some hundreds) run .../elf/ld-linux.so.2 explicitly, and normally this is a symlink to the real executable .../elf/ld.so. So just sever the link, and make .../elf/ld-linux.so.2 be an executable shell script that runs valgrind .../elf/ld.so "$@" . The raw coverage is somewhat good, the coverage of typical usage is so-so. Most individual features get tested, but in stylized scenarios that can avoid the interactions that may be present in user code. I've run it a few times, and produced a false positive complaint from memcheck ("don't care" with partial undefined is not tracked correctly), an occasional hang in thread code, and some "uninit" bugs in glibc. -- |
|
From: Tom H. <to...@co...> - 2006-02-14 14:57:40
|
In message <43F...@wa...>
Eric Pouech <eri...@wa...> wrote:
> Tom Hughes wrote:
>
> > I think the correct solution to the trap number problem is to make
> > sure we propagate it from the original kernel delivered signal
> > frame to the one we create for the client program, but that is
> > slightly complicated. We would also need to fake something up when
> > we synthesise a signal.
>
> I didn't see any place where you get the trap-no from a rt signal
> handler on x86, or did I miss something ?
Well that's the point... The path for a normal signal that originates
from the kernel is like this:
- signal delivered to sync_signalhandler or async_signalhandler
- at this point we have a ucontext with a trapno in it
- signal passed to deliver_signal
- here the ucontext is lost as it is not passed in
- push_signal_frame called to construct frame for client program
- platform specific VG_(sigframe_create) called to construct frame
- build_rt_sigframe or build_sigframe called
- synth_ucontext called
- here we need to store the trap number in the created ucontext
What you proposed is that synth_ucontext should try and guess the
trap number from the signal number and code.
I am suggesting that the original kernel ucontext should be propagated
down through that call stack so that synth_ucontext can take the
original kernel supplied trap number from it which is guaranteed to
be accurate.
The only problem is that deliver_signal is called from other places
like synth_fault_common, synth_sigill and synth_sigtrap which would
have to invent a ucontext with an appropriate trap number or something.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-02-14 13:55:44
|
> I'd also like to see a semi-working helgrind again :) Well, so would everybody. It requires finding someone with the time and skills to do it though. At least it is possible again now that the trunk does function wrapping. > > Of the bugs listed in docs/internals/3_1_BUGSTATUS.txt, are there any > > that are particularly critical for you? > > No, none that I know of. I guess we should just backport whatever trivial > bugfixes still left from trunk, and release this as 3.1.1. Yes, ok. We should make a pass through the mail lists to update 3_1_BUGSTATUS, and then we can decide which ones to fix/backport. J |
|
From: Eric P. <eri...@wa...> - 2006-02-14 13:28:23
|
Tom Hughes wrote: > In message <43F...@wa...> > Eric Pouech <eri...@wa...> wrote: > > >>Tom Hughes wrote: >> >> >>>>I dunno (I do have the same thoughts about it). My point was not to make >>>>a 100% accurate patch, but at least to show the areas that needed to be >>>>improved. IMO, the best solution would be not to ask for a RT signal >>>>handler if the user doesn't ask for (there's nothing to be done here, >>>>just passing the information), but it complicates a bit the signal >>>>handling code on V side. >>> >>>I'm not sure I understand what you mean there - regardless of what >>>sort of handler valgrind asks the kernel for it should always be >>>presenting the right sort (rt or non-rt) of signal frame to the >>>application's handler. >> >>I was talking about the sig handler valgrinds asks for to the kernel. >>IMO, if we want to get the mappings 100% right from the kernel, we >>should do something like: >>- if the user asks for a non rt sig handler, vg should ask for a non rt >>sig handler >>- if the user asks for a rt sig handler, vg should ask for a rt sig handler >>of course, that would duplicate all the sig handler code > > > I understand what you are suggesting, but why do you think we need to > do it? and what does it have to do with the trap number stuff? > > The rt handlers are effectvely a superset of the non-rt ones so we > can always construct a valid non-rt signal frame based on an rt > signal frames supplied to us by the kernel, which is what we do. > > In other words it should be transparent to the application running > under valgrind that valgrind is always asking the kernel for rt > signal frames. You seem to think that it is not transparent for > some reason? > > I think the correct solution to the trap number problem is to make > sure we propagate it from the original kernel delivered signal > frame to the one we create for the client program, but that is > slightly complicated. We would also need to fake something up when > we synthesise a signal. I didn't see any place where you get the trap-no from a rt signal handler on x86, or did I miss something ? A+ -- Eric Pouech |
|
From: Dirk M. <dm...@gm...> - 2006-02-14 13:21:03
|
On Tuesday, 14. February 2006 13:48, Julian Seward wrote: > Yes we should definitely release something soon. Half of me thinks there > have been so many fixes in the head now that it would be less effort to > do a release from the trunk (3.2.0 ?) rather than 3.1.1. But it would be > nice to merge in Nick's new memcheck stuff, and Callgrind, for 3.2.0, > which will take some time. So maybe 3.1.1 is unavoidable. I'd also like to see a semi-working helgrind again :) > Of the bugs listed in docs/internals/3_1_BUGSTATUS.txt, are there any > that are particularly critical for you? No, none that I know of. I guess we should just backport whatever trivial bugfixes still left from trunk, and release this as 3.1.1. Dirk |
|
From: Julian S. <js...@ac...> - 2006-02-14 12:49:01
|
> Its a long time already since 3.1.0 release, how are the plans for a 3.1.1 > release? Yes we should definitely release something soon. Half of me thinks there have been so many fixes in the head now that it would be less effort to do a release from the trunk (3.2.0 ?) rather than 3.1.1. But it would be nice to merge in Nick's new memcheck stuff, and Callgrind, for 3.2.0, which will take some time. So maybe 3.1.1 is unavoidable. 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. Of the bugs listed in docs/internals/3_1_BUGSTATUS.txt, are there any that are particularly critical for you? J |
|
From: <js...@ac...> - 2006-02-14 11:57:15
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-02-14 05: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: <sv...@va...> - 2006-02-14 11:37:52
|
Author: sewardj
Date: 2006-02-14 11:37:41 +0000 (Tue, 14 Feb 2006)
New Revision: 5647
Log:
Ensure memory acquired from sys_brk() really is zeroed. Fixes #121893.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/docs/internals/3_1_BUGSTATUS.txt
Modified: trunk/coregrind/m_syswrap/syswrap-generic.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_syswrap/syswrap-generic.c 2006-02-13 18:16:41 UTC (=
rev 5646)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2006-02-14 11:37:41 UTC (=
rev 5647)
@@ -947,6 +947,23 @@
if (seg && seg->hasT)
VG_(discard_translations)( newbrk, VG_(brk_limit) - newbrk,=20
"do_brk(shrink)" );
+ /* Since we're being lazy and not unmapping pages, we have to
+ zero out the area, so that if the area later comes back into
+ circulation, it will be filled with zeroes, as if it really
+ had been unmapped and later remapped. Be a bit paranoid and
+ try hard to ensure we're not going to segfault by doing the
+ write - check both ends of the range are in the same segment
+ and that segment is writable. */
+ if (seg) {
+ /* pre: newbrk < VG_(brk_limit)=20
+ =3D> newbrk <=3D VG_(brk_limit)-1 */
+ NSegment* seg2;
+ vg_assert(newbrk < VG_(brk_limit));
+ seg2 =3D VG_(am_find_nsegment)( VG_(brk_limit)-1 );
+ if (seg2 && seg =3D=3D seg2 && seg->hasW)
+ VG_(memset)( (void*)newbrk, 0, VG_(brk_limit) - newbrk );
+ }
+
VG_(brk_limit) =3D newbrk;
return newbrk;
}
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-13 18:16:41 UTC (rev 5=
646)
+++ trunk/docs/internals/3_1_BUGSTATUS.txt 2006-02-14 11:37:41 UTC (rev 5=
647)
@@ -53,9 +53,9 @@
120277 unimplemented PPC floating point instructions: fres, fctid,
fctidz, frsqrte
=20
+v5647 pending 121893 calloc does not always zero memory
=20
=20
-
don't forget:
Dave Nomura extra suppression (dev, Tue Jan 17 00:14:30 2006)
Control-Z bug
|
|
From: Julian S. <js...@ac...> - 2006-02-14 11:33:18
|
> Is there a set of standard test scenarios that you've run Valgrind under > other than the regression test suite? The only other one used is to run the test suite for the GNU Scientific Library v 1.6 on Valgrind. http://www.gnu.org/software/gsl. GSL 1.6 is 252000 lines of C, is very portable, and has an excellent test suite of over 100000 tests. I've found it effective in finding obscure instruction emulation bugs in both integer and FP code, and much of the reliability of vex compilation pipeline comes from testing with GSL. To make running the tests easy I made the script auxprogs/gsl16test. This is not run as part of the automated nightly builds, though. Perhaps it should. Even the quickest run of a gsl test takes about an hour. Apart from that .. nothing. Informally, we try to ensure that OpenOffice and Mozilla work prior to each release, but this is not a very methodical test. One thing to point out is that tests which run as part of the overnight builds are much more effective at keeping the system reliable than is a few one-off tests, eg you running OOo or Mozilla or whatever from time to time. Bottom line is, if you want functionality to work reliably, you need to have it tested every night, on all platforms. The instruction-emulation aspects of testing Valgrind are fairly well covered. What is weaker is our testing of simulation of threads, signals, syscalls, etc. At some point in the past Jeremy Fitzhardinge was using an open source POSIX conformance suite to test the signals, threads, etc, aspects of Valgrind. That sounds like a very useful thing. In my view it would be an effective way to ensure the kind of robustness you are looking for - more effective than running standard Linux utilities, since running standard utilities gives us no real idea of what functionality is tested and what isn't. Plus we can't easily integrate that kind of thing into the test suite. J |
|
From: <js...@ac...> - 2006-02-14 03:58:49
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-02-14 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, 7 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (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: <js...@ac...> - 2006-02-14 03:57:21
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-02-14 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: Tom H. <to...@co...> - 2006-02-14 03:43:47
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2006-02-14 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-14 03:30:23
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-02-14 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-14 03:23:59
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2006-02-14 03:10:05 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, 2 stdout failures ================= memcheck/tests/leakotron (stdout) 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, 2 stdout failures ================= 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/pth_cvsimple (stdout) none/tests/x86/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Feb 14 03:17:23 2006 --- new.short Tue Feb 14 03:23:53 2006 *************** *** 8,11 **** ! == 245 tests, 6 stderr failures, 2 stdout failures ================= ! memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) --- 8,11 ---- ! == 245 tests, 5 stderr failures, 2 stdout failures ================= ! memcheck/tests/leakotron (stdout) memcheck/tests/x86/scalar (stderr) *************** *** 14,16 **** none/tests/amd64/faultstatus (stderr) - none/tests/pth_cvsimple (stdout) none/tests/x86/faultstatus (stderr) --- 14,15 ---- |
|
From: Tom H. <th...@cy...> - 2006-02-14 03:20:45
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2006-02-14 03:05:08 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) |
|
From: Tom H. <th...@cy...> - 2006-02-14 03:18:55
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-02-14 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) |