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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(11) |
2
(14) |
3
(11) |
|
4
(7) |
5
(14) |
6
(15) |
7
(31) |
8
(12) |
9
(9) |
10
(9) |
|
11
(9) |
12
(10) |
13
(10) |
14
(9) |
15
(10) |
16
(11) |
17
(10) |
|
18
(10) |
19
(10) |
20
(11) |
21
(13) |
22
(16) |
23
(9) |
24
(7) |
|
25
(9) |
26
(7) |
27
(9) |
28
(5) |
29
(5) |
30
(9) |
|
|
From: John C. <joh...@ta...> - 2006-06-22 00:03:29
|
On Wed, 21 Jun 2006, Tom Hughes wrote: > I've checked in a fix for this now - it was an off by one error in > the boundary condition being checked by the assertion which would > cause it to fire when you tried to expand into the final page of the > space reserved for the heap. Thanks! That's marvelous! I checked it out and it worked, assertion gone away! Do you still want me to enter it into bug tracker? I notice that it valgrind still refuses to shift the brk by more than about 8mb (0x7ff001 to be precise) Is there a way of increasing that limit? (I have appended the output of valgrind -v -d ./brk to this mail.... John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : joh...@ta... New Zealand Carter's Clarification of Murphy's Law. "Things only ever go right so that they may go more spectacularly wrong later." >From this principle, all of life and physics may be deduced. ====================================================================== valgrind -v -d ./brk --8182:1:debuglog DebugLog system started by Stage 1, level 1 logging requested --8182:1:launcher no tool requested, defaulting to 'memcheck' --8182:1:launcher selected platform 'x86-linux' --8182:1:launcher launching /usr/local/lib/valgrind/x86-linux/memcheck --8182:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested --8182:1:main Welcome to Valgrind version 3.3.0.SVN debug logging --8182:1:main Checking current stack is plausible --8182:1:main Checking initial stack was noted --8182:1:main Starting the address space manager --8182:1:main Address space manager is running --8182:1:main Starting the dynamic memory manager --8182:1:mallocfr newSuperblock at 0x61F7F000 (pszB 1048560) owner VALGRIND/tool --8182:1:main Dynamic memory manager is running --8182:1:main Getting stage1's name --8182:1:main Get hardware capabilities ... --8182:1:main ... arch = X86, hwcaps = x86-sse1-sse2 --8182:1:main Split up command line --8182:1:main Preprocess command line opts --8182:1:main Loading client --8182:1:main Setup client env --8182:1:main Setup client stack --8182:1:main Setup client data (brk) segment --8182:1:main Setup file descriptors --8182:1:main Create fake /proc/<pid>/cmdline --8182:1:main Initialise the tool part 1 (pre_clo_init) --8182:1:main Print help and quit, if requested --8182:1:main Process Valgrind's command line options, setup logging --8182:1:mallocfr newSuperblock at 0x6207F000 (pszB 1048560) owner VALGRIND/core --8182:1:main Print the preamble... ==8182== Memcheck, a memory error detector. ==8182== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==8182== Using LibVEX rev 1631, a library for dynamic binary translation. ==8182== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==8182== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==8182== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==8182== --8182-- Command line --8182-- ./brk --8182-- Startup, with flags: --8182-- -v --8182-- -d --8182-- Contents of /proc/version: --8182-- Linux version 2.6.15.1 (johnc@parore) (gcc version 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)) #0 PREEMPT Tue Mar 21 08:57:50 NZST 2006 --8182-- Arch and hwcaps: X86, x86-sse1-sse2 --8182-- Valgrind library directory: /usr/local/lib/valgrind --8182:1:main ...finished the preamble --8182:1:main Initialise the tool part 2 (post_clo_init) --8182:1:main Initialise TT/TC --8182:1:main Initialise redirects --8182:1:mallocfr newSuperblock at 0x621FA000 (pszB 1048560) owner VALGRIND/symtab --8182:1:main Load initial debug info --8182-- Reading syms from /lib/ld-2.3.6.so (0x4000000) --8182-- Reading debug info from /lib/ld-2.3.6.so... --8182-- ... CRC mismatch (computed A0828FFB wanted BF5D33FD) --8182-- object doesn't have a symbol table --8182-- Reading syms from /home/johnc/tmp/brk (0x8048000) --8182-- Reading syms from /usr/local/lib/valgrind/x86-linux/memcheck (0x38000000) --8182-- object doesn't have a dynamic symbol table --8182:1:mallocfr newSuperblock at 0x622FA000 (pszB 1048560) owner VALGRIND/symtab --8182:1:mallocfr newSuperblock at 0x623FA000 (pszB 1048560) owner VALGRIND/symtab --8182:1:redir transfer ownership V -> C of 0x38027000 .. 0x38027FFF --8182:1:main Tell tool about initial permissions --8182:1:main Initialise scheduler --8182:1:main Initialise thread 1's state --8182:1:main Initialise signal management --8182:1:main Load suppressions --8182-- Reading suppressions file: /usr/local/lib/valgrind/default.supp --8182:1:main --8182:1:main --8182:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (25 segments, 3 segnames) --8182:1:aspacem ( 0) /usr/local/lib/valgrind/x86-linux/memcheck --8182:1:aspacem ( 1) /home/johnc/tmp/brk --8182:1:aspacem ( 2) /lib/ld-2.3.6.so --8182:1:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed --8182:1:aspacem 1: file 0004000000-0004014FFF 86016 r-x-- d=0x302 i=213532 o=0 (2) --8182:1:aspacem 2: file 0004015000-0004016FFF 8192 rw--- d=0x302 i=213532 o=86016 (2) --8182:1:aspacem 3: 0004017000-0008047FFF 64m --8182:1:aspacem 4: file 0008048000-0008048FFF 4096 r-x-- d=0x304 i=105621 o=0 (1) --8182:1:aspacem 5: file 0008049000-0008049FFF 4096 rw--- d=0x304 i=105621 o=0 (1) --8182:1:aspacem 6: anon 000804A000-000804AFFF 4096 rwx-- --8182:1:aspacem 7: RSVN 000804B000-0008849FFF 8384512 ----- SmLower --8182:1:aspacem 8: 000884A000-0037FFFFFF 759m --8182:1:aspacem 9: FILE 0038000000-0038026FFF 159744 r-x-- d=0x302 i=574341 o=0 (0) --8182:1:aspacem 10: file 0038027000-0038027FFF 4096 r-x-- d=0x302 i=574341 o=159744 (0) --8182:1:aspacem 11: FILE 0038028000-0038151FFF 1220608 r-x-- d=0x302 i=574341 o=163840 (0) --8182:1:aspacem 12: FILE 0038152000-0038152FFF 4096 rw--- d=0x302 i=574341 o=1380352 (0) --8182:1:aspacem 13: ANON 0038153000-003883CFFF 7249920 rw--- --8182:1:aspacem 14: 003883D000-0061F7DFFF 663m --8182:1:aspacem 15: RSVN 0061F7E000-0061F7EFFF 4096 ----- SmFixed --8182:1:aspacem 16: ANON 0061F7F000-0062509FFF 5812224 rwx-- --8182:1:aspacem 17: 006250A000-00BE6FCFFF 1473m --8182:1:aspacem 18: RSVN 00BE6FD000-00BEEFBFFF 8384512 ----- SmUpper --8182:1:aspacem 19: anon 00BEEFC000-00BEEFCFFF 4096 rwx-- --8182:1:aspacem 20: 00BEEFD000-00BFEE8FFF 15m --8182:1:aspacem 21: ANON 00BFEE9000-00BFEFEFFF 90112 rw--- --8182:1:aspacem 22: RSVN 00BFEFF000-00FFFFDFFF 1024m ----- SmFixed --8182:1:aspacem 23: ANON 00FFFFE000-00FFFFEFFF 4096 ----- --8182:1:aspacem 24: RSVN 00FFFFF000-00FFFFFFFF 4096 ----- SmFixed --8182:1:aspacem >>> --8182:1:main --8182:1:main --8182:1:main Running thread 1 --8182:1:syswrap- entering VG_(main_thread_wrapper_NORETURN) --8182:1:aspacem allocated thread stack at 0x6250A000 size 81920 --8182:1:syswrap- run_a_thread_NORETURN(tid=1): pre-thread_wrapper --8182:1:syswrap- thread_wrapper(tid=1): entry --8182:1:transtab allocate sector 0 --8182:1:mallocfr newSuperblock at 0x63D10000 (pszB 65520) owner VALGRIND/ttaux --8182:1:signals extending a stack base 0xBEEFC000 down by 4096 --8182-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_core.so (0x4019000) --8182-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x401B000) --8182-- Reading syms from /lib/tls/i686/cmov/libc-2.3.6.so (0x403F000) --8182-- Reading debug info from /lib/tls/i686/cmov/libc-2.3.6.so... --8182-- ... CRC mismatch (computed 1C5E30FA wanted 551808F8) --8182-- object doesn't have a symbol table --8182:1:mallocfr newSuperblock at 0x63D28000 (pszB 262128) owner VALGRIND/exectxt --8182:1:mallocfr newSuperblock at 0x63D68000 (pszB 65520) owner VALGRIND/errors --8182-- REDIR: 0x40AD090 (rindex) redirected to 0x401DF20 (rindex) Current brk = 0x804a000 brk first failed at size 8384513 (or 7ff001 in hex) --8182:1:syswrap- thread_wrapper(tid=1): exit --8182:1:syswrap- run_a_thread_NORETURN(tid=1): post-thread_wrapper --8182:1:syswrap- run_a_thread_NORETURN(tid=1): last one standing --8182:1:main entering VG_(shutdown_actions_NORETURN) --8182-- REDIR: 0x40A5B40 (free) redirected to 0x401CEE9 (free) --8182-- REDIR: 0x40ADF40 (memset) redirected to 0x401E3C0 (memset) ==8182== ==8182== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 1) --8182-- --8182-- supp: 11 Ubuntu-stripped-ld.so ==8182== malloc/free: in use at exit: 0 bytes in 0 blocks. ==8182== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==8182== ==8182== All heap blocks were freed -- no leaks are possible. --8182-- memcheck: sanity checks: 754 cheap, 31 expensive --8182-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use --8182-- memcheck: auxmaps: 0 searches, 0 comparisons --8182-- memcheck: SMs: n_issued = 135 (2160k, 2M) --8182-- memcheck: SMs: n_deissued = 0 (0k, 0M) --8182-- memcheck: SMs: max_noaccess = 65535 (1048560k, 1023M) --8182-- memcheck: SMs: max_undefined = 0 (0k, 0M) --8182-- memcheck: SMs: max_defined = 21 (336k, 0M) --8182-- memcheck: SMs: max_non_DSM = 135 (2160k, 2M) --8182-- memcheck: max sec V bit nodes: 1 (0k, 0M) --8182-- memcheck: set_sec_vbits8 calls: 1 (new: 1, updates: 0) --8182-- memcheck: max shadow mem size: 2464k, 2M --8182-- translate: fast SP updates identified: 1,630 ( 90.1%) --8182-- translate: generic_known SP updates identified: 90 ( 4.9%) --8182-- translate: generic_unknown SP updates identified: 89 ( 4.9%) --8182-- tt/tc: 3,471 tt lookups requiring 3,498 probes --8182-- tt/tc: 3,471 fast-cache updates, 2 flushes --8182-- transtab: new 1,733 (36,167 -> 601,023; ratio 166:10) [0 scs] --8182-- transtab: dumped 0 (0 -> ??) --8182-- transtab: discarded 0 (0 -> ??) --8182-- scheduler: 75,486,374 jumps (bb entries). --8182-- scheduler: 754/8,386,964 major/minor sched events. --8182-- sanity: 755 cheap, 31 expensive checks. --8182-- exectx: 30,011 lists, 6 contexts (avg 0 per list) --8182-- exectx: 11 searches, 5 full compares (454 per 1000) --8182-- exectx: 0 cmp2, 26 cmp4, 0 cmpAll --8182:1:core_os VG_(terminate_NORETURN)(tid=1) |
|
From: Tom H. <to...@co...> - 2006-06-21 08:45:08
|
In message <819...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <200...@gm...>
> Josef Weidendorfer <Jos...@gm...> wrote:
>
>> Can it theoretically be some corruption produced by callgrinds
>> instrumentation?
>
> Well that was my first thought, but the behaviour should be consistent
> in that case - each run should fail, and in the same place.
I've reproduced it with --tool=none now so we can rule out callgrind
having any involvement in the problem.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2006-06-21 08:03:56
|
Author: tom Date: 2006-06-21 09:03:48 +0100 (Wed, 21 Jun 2006) New Revision: 5975 Log: Document bug fix. Modified: trunk/docs/internals/3_2_BUGSTATUS.txt Modified: trunk/docs/internals/3_2_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_2_BUGSTATUS.txt 2006-06-21 08:01:14 UTC (rev 5= 974) +++ trunk/docs/internals/3_2_BUGSTATUS.txt 2006-06-21 08:03:48 UTC (rev 5= 975) @@ -8,6 +8,8 @@ =20 TRUNK PRIO BUG# WHAT =20 +v5974 n-i-bz Expanding brk() into last available page asse= rts + ------- Bugs reported prior to 3.2.0 ------ =20 TRUNK 32BRANCH BUG# WHAT |
|
From: Tom H. <to...@co...> - 2006-06-21 08:03:03
|
In message <Pine.LNX.4.64.0606211441360.18087@parore>
John Carter <joh...@ta...> wrote:
> Valgrind is balking at perform a large brk() move.
>
> So I wrote a very simple program to try every value from large to none
> and find the point at which it first succeeds.
>
> I think the results are quite instructive (assertion failure) and will
> pinpoint the bug....
I've checked in a fix for this now - it was an off by one error in
the boundary condition being checked by the assertion which would
cause it to fire when you tried to expand into the final page of the
space reserved for the heap.
It turned out that we were also allowing the heap to grow by one
less byte than we should have been so I've fixed that as well.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <sv...@va...> - 2006-06-21 08:01:23
|
Author: tom
Date: 2006-06-21 09:01:14 +0100 (Wed, 21 Jun 2006)
New Revision: 5974
Log:
Fix boundary case when trying to use brk() to expand right up to the
limit of the brk segment.
Because VG_(brk_limit) is the first address beyond the end of the
memory available to the caller of brk() we need to allow it to grow
up to and including the address one page below the end of the space
valgrind has reserved.
Modified:
trunk/coregrind/m_syswrap/syswrap-generic.c
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-06-16 21:39:08 UTC (=
rev 5973)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2006-06-21 08:01:14 UTC (=
rev 5974)
@@ -989,14 +989,14 @@
return newbrk;
}
=20
- if (newbrk >=3D rseg->end+1 - VKI_PAGE_SIZE) {
+ if (newbrk > rseg->end+1 - VKI_PAGE_SIZE) {
/* request is too large -- the resvn would fall below 1 page,
which isn't allowed. */
goto bad;
}
=20
newbrkP =3D VG_PGROUNDUP(newbrk);
- vg_assert(newbrkP > rseg->start && newbrkP < rseg->end+1 - VKI_PAGE_S=
IZE);
+ vg_assert(newbrkP > rseg->start && newbrkP <=3D rseg->end+1 - VKI_PAG=
E_SIZE);
delta =3D newbrkP - rseg->start;
vg_assert(delta > 0);
vg_assert(VG_IS_PAGE_ALIGNED(delta));
|
|
From: Tom H. <to...@co...> - 2006-06-21 07:37:11
|
In message <Pine.LNX.4.64.0606211441360.18087@parore>
John Carter <joh...@ta...> wrote:
> Valgrind is balking at perform a large brk() move.
>
> So I wrote a very simple program to try every value from large to none
> and find the point at which it first succeeds.
>
> I think the results are quite instructive (assertion failure) and will
> pinpoint the bug....
Indeed, and I can reproduce it. Can you raise a bug on the bug
tracker for it please?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: John C. <joh...@ta...> - 2006-06-21 03:55:57
|
Valgrind is balking at perform a large brk() move.
So I wrote a very simple program to try every value from large to none
and find the point at which it first succeeds.
I think the results are quite instructive (assertion failure) and will
pinpoint the bug....
Here is the program....
==brk.c===============================================================
#include <unistd.h>
#include <stdio.h>
int main()
{
void * current_brk = sbrk(0);
int n = 1;
int result;
printf("Current brk = %p\n", current_brk);
for( n=0xa00000;n>0;--n) {
result = brk(current_brk+n);
if( !result) {
printf( "brk first succeeded at size %d (or %x in hex)\n", n, n);
return 0;
}
}
return 0;
}
======================================================================
It compiles without warnings under -Wall -W under gcc 4.1.0
Running normally not under valgrind the output is...
Current brk = 0x804a000
brk first succeeded at size 10485760 (or a00000 in hex)
Running under valgrind (svn latest as of today....)
======================================================================
valgrind -v -d ./brk
--26015:1:debuglog DebugLog system started by Stage 1, level 1 logging requested
--26015:1:launcher no tool requested, defaulting to 'memcheck'
--26015:1:launcher selected platform 'x86-linux'
--26015:1:launcher launching /usr/local/lib/valgrind/x86-linux/memcheck
--26015:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested
--26015:1:main Welcome to Valgrind version 3.3.0.SVN debug logging
--26015:1:main Checking current stack is plausible
--26015:1:main Checking initial stack was noted
--26015:1:main Starting the address space manager
--26015:1:main Address space manager is running
--26015:1:main Starting the dynamic memory manager
--26015:1:mallocfr newSuperblock at 0x61EBE000 (pszB 1048560) owner VALGRIND/tool
--26015:1:main Dynamic memory manager is running
--26015:1:main Getting stage1's name
--26015:1:main Get hardware capabilities ...
--26015:1:main ... arch = X86, hwcaps = x86-sse1-sse2
--26015:1:main Split up command line
--26015:1:main Preprocess command line opts
--26015:1:main Loading client
--26015:1:main Setup client env
--26015:1:main Setup client stack
--26015:1:main Setup client data (brk) segment
--26015:1:main Setup file descriptors
--26015:1:main Create fake /proc/<pid>/cmdline
--26015:1:main Initialise the tool part 1 (pre_clo_init)
--26015:1:main Print help and quit, if requested
--26015:1:main Process Valgrind's command line options, setup logging
--26015:1:mallocfr newSuperblock at 0x61FBE000 (pszB 1048560) owner VALGRIND/core
--26015:1:main Print the preamble...
==26015== Memcheck, a memory error detector.
==26015== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==26015== Using LibVEX rev 1631, a library for dynamic binary translation.
==26015== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==26015== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework.
==26015== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==26015==
--26015-- Command line
--26015-- ./brk
--26015-- Startup, with flags:
--26015-- -v
--26015-- -d
--26015-- Contents of /proc/version:
--26015-- Linux version 2.6.15.1 (johnc@parore) (gcc version 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)) #0 PREEMPT Tue Mar 21 08:57:50 NZST 2006
--26015-- Arch and hwcaps: X86, x86-sse1-sse2
--26015-- Valgrind library directory: /usr/local/lib/valgrind
--26015:1:main ...finished the preamble
--26015:1:main Initialise the tool part 2 (post_clo_init)
--26015:1:main Initialise TT/TC
--26015:1:main Initialise redirects
--26015:1:mallocfr newSuperblock at 0x62139000 (pszB 1048560) owner VALGRIND/symtab
--26015:1:main Load initial debug info
--26015-- Reading syms from /lib/ld-2.3.6.so (0x4000000)
--26015-- Reading debug info from /lib/ld-2.3.6.so...
--26015-- ... CRC mismatch (computed A0828FFB wanted BF5D33FD)
--26015-- object doesn't have a symbol table
--26015-- Reading syms from /home/johnc/tmp/brk (0x8048000)
--26015-- Reading syms from /usr/local/lib/valgrind/x86-linux/memcheck (0x38000000)
--26015-- object doesn't have a dynamic symbol table
--26015:1:mallocfr newSuperblock at 0x62239000 (pszB 1048560) owner VALGRIND/symtab
--26015:1:mallocfr newSuperblock at 0x62339000 (pszB 1048560) owner VALGRIND/symtab
--26015:1:redir transfer ownership V -> C of 0x38027000 .. 0x38027FFF
--26015:1:main Tell tool about initial permissions
--26015:1:main Initialise scheduler
--26015:1:main Initialise thread 1's state
--26015:1:main Initialise signal management
--26015:1:main Load suppressions
--26015-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--26015:1:main
--26015:1:main
--26015:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (25 segments, 3 segnames)
--26015:1:aspacem ( 0) /usr/local/lib/valgrind/x86-linux/memcheck
--26015:1:aspacem ( 1) /home/johnc/tmp/brk
--26015:1:aspacem ( 2) /lib/ld-2.3.6.so
--26015:1:aspacem 0: RSVN 0000000000-0003FFFFFF 64m ----- SmFixed
--26015:1:aspacem 1: file 0004000000-0004014FFF 86016 r-x-- d=0x302 i=213532 o=0 (2)
--26015:1:aspacem 2: file 0004015000-0004016FFF 8192 rw--- d=0x302 i=213532 o=86016 (2)
--26015:1:aspacem 3: 0004017000-0008047FFF 64m
--26015:1:aspacem 4: file 0008048000-0008048FFF 4096 r-x-- d=0x304 i=105621 o=0 (1)
--26015:1:aspacem 5: file 0008049000-0008049FFF 4096 rw--- d=0x304 i=105621 o=0 (1)
--26015:1:aspacem 6: anon 000804A000-000804AFFF 4096 rwx--
--26015:1:aspacem 7: RSVN 000804B000-0008849FFF 8384512 ----- SmLower
--26015:1:aspacem 8: 000884A000-0037FFFFFF 759m
--26015:1:aspacem 9: FILE 0038000000-0038026FFF 159744 r-x-- d=0x302 i=574341 o=0 (0)
--26015:1:aspacem 10: file 0038027000-0038027FFF 4096 r-x-- d=0x302 i=574341 o=159744 (0)
--26015:1:aspacem 11: FILE 0038028000-0038151FFF 1220608 r-x-- d=0x302 i=574341 o=163840 (0)
--26015:1:aspacem 12: FILE 0038152000-0038152FFF 4096 rw--- d=0x302 i=574341 o=1380352 (0)
--26015:1:aspacem 13: ANON 0038153000-003883CFFF 7249920 rw---
--26015:1:aspacem 14: 003883D000-0061EBCFFF 662m
--26015:1:aspacem 15: RSVN 0061EBD000-0061EBDFFF 4096 ----- SmFixed
--26015:1:aspacem 16: ANON 0061EBE000-0062448FFF 5812224 rwx--
--26015:1:aspacem 17: 0062449000-00BE579FFF 1473m
--26015:1:aspacem 18: RSVN 00BE57A000-00BED78FFF 8384512 ----- SmUpper
--26015:1:aspacem 19: anon 00BED79000-00BED79FFF 4096 rwx--
--26015:1:aspacem 20: 00BED7A000-00BFD66FFF 15m
--26015:1:aspacem 21: ANON 00BFD67000-00BFD7CFFF 90112 rw---
--26015:1:aspacem 22: RSVN 00BFD7D000-00FFFFDFFF 1026m ----- SmFixed
--26015:1:aspacem 23: ANON 00FFFFE000-00FFFFEFFF 4096 -----
--26015:1:aspacem 24: RSVN 00FFFFF000-00FFFFFFFF 4096 ----- SmFixed
--26015:1:aspacem >>>
--26015:1:main
--26015:1:main
--26015:1:main Running thread 1
--26015:1:syswrap- entering VG_(main_thread_wrapper_NORETURN)
--26015:1:aspacem allocated thread stack at 0x62449000 size 81920
--26015:1:syswrap- run_a_thread_NORETURN(tid=1): pre-thread_wrapper
--26015:1:syswrap- thread_wrapper(tid=1): entry
--26015:1:transtab allocate sector 0
--26015:1:mallocfr newSuperblock at 0x63C4F000 (pszB 65520) owner VALGRIND/ttaux
--26015:1:signals extending a stack base 0xBED79000 down by 4096
--26015-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_core.so (0x4019000)
--26015-- Reading syms from /usr/local/lib/valgrind/x86-linux/vgpreload_memcheck.so (0x401B000)
--26015-- Reading syms from /lib/tls/i686/cmov/libc-2.3.6.so (0x403F000)
--26015-- Reading debug info from /lib/tls/i686/cmov/libc-2.3.6.so...
--26015-- ... CRC mismatch (computed 1C5E30FA wanted 551808F8)
--26015-- object doesn't have a symbol table
--26015:1:mallocfr newSuperblock at 0x63C67000 (pszB 262128) owner VALGRIND/exectxt
--26015:1:mallocfr newSuperblock at 0x63CA7000 (pszB 65520) owner VALGRIND/errors
--26015-- REDIR: 0x40AD090 (rindex) redirected to 0x401DF20 (rindex)
valgrind: m_syswrap/syswrap-generic.c:999 (do_brk): Assertion 'newbrkP > rseg->start && newbrkP < rseg->end+1 - VKI_PAGE_SIZE' failed.
==26015== at 0x38016587: report_and_quit (m_libcassert.c:136)
==26015== by 0x380168B3: vgPlain_assert_fail (m_libcassert.c:200)
==26015== by 0x38043E65: vgSysWrap_generic_sys_brk_before (syswrap-generic.c:999)
==26015== by 0x3804B4EE: vgPlain_client_syscall (syswrap-main.c:719)
==26015== by 0x38037CF3: vgPlain_scheduler (scheduler.c:721)
==26015== by 0x38056AC2: run_a_thread_NORETURN (syswrap-linux.c:87)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==26015== at 0x4000792: (within /lib/ld-2.3.6.so)
==26015== by 0x804842C: main (in /home/johnc/tmp/brk)
Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.
If that doesn't help, please report this bug to: www.valgrind.org
In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using. Thanks.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : joh...@ta...
New Zealand
Carter's Clarification of Murphy's Law.
"Things only ever go right so that they may go more spectacularly wrong later."
>From this principle, all of life and physics may be deduced.
|
|
From: <js...@ac...> - 2006-06-21 03:03:17
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-06-21 03:30:01 BST 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 == 235 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-21 02:55:31
|
Nightly build on ford ( i686, Fedora Core 4 ) started at 2006-06-21 03:25:08 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 == 235 tests, 5 stderr failures, 0 stdout failures, 0 posttest 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) |
|
From: Tom H. <to...@co...> - 2006-06-21 02:46:04
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-06-21 03:30:04 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 == 237 tests, 5 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-21 02:32:35
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-06-21 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 == 236 tests, 19 stderr failures, 0 stdout failures, 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-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/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-21 02:30:13
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2006-06-21 03:10:06 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 == 236 tests, 6 stderr failures, 0 stdout failures, 0 posttest failures == 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/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-21 02:28:11
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-06-21 03:10: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 == 260 tests, 2 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-21 02:21:53
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-06-21 03:00:04 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 == 260 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) |
|
From: Tom H. <to...@co...> - 2006-06-20 16:37:27
|
In message <200...@gm...>
Josef Weidendorfer <Jos...@gm...> wrote:
> On Tuesday 20 June 2006 17:08, Tom Hughes wrote:
> > Instrumenting the code has shown that the problem is the floating
> > point control word which is 0x37f at the end of the inner loop instead
> > of the expected value of 0x27f. That corresponds to changing from
> > double precision to double extended precision.
> >
> > Does anybody have any suggestions where I can go from here to track
> > this down? Is this likely to be a kernel bug with the kernel not
> > restoring the control word properly on a context switch? That seems
> > very unlikely somehow but it's the only scenario I've come up with
> > so far to explain what I'm seeing.
>
> Hmmm... Not that I understand the issue, but it worries me:
Basically before executing each chunk of translated code valgrind
sets the FPU and vector unit control registers to known values and
then when the translated code finishes executing it checks that
they are the same and asserts if they aren't.
In this case it is bits 8+9 of the FPU control word which seem to
be changing - they control the precision to which x87 instructions
operate.
> Can it theoretically be some corruption produced by callgrinds
> instrumentation?
Well that was my first thought, but the behaviour should be consistent
in that case - each run should fail, and in the same place.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Josef W. <Jos...@gm...> - 2006-06-20 16:21:21
|
On Tuesday 20 June 2006 17:08, Tom Hughes wrote: > Instrumenting the code has shown that the problem is the floating > point control word which is 0x37f at the end of the inner loop instead > of the expected value of 0x27f. That corresponds to changing from > double precision to double extended precision. > > Does anybody have any suggestions where I can go from here to track > this down? Is this likely to be a kernel bug with the kernel not > restoring the control word properly on a context switch? That seems > very unlikely somehow but it's the only scenario I've come up with > so far to explain what I'm seeing. Hmmm... Not that I understand the issue, but it worries me: Can it theoretically be some corruption produced by callgrinds instrumentation? Probably not if this depends on the kernels scheduling... Josef |
|
From: Tom H. <to...@co...> - 2006-06-20 16:05:50
|
One of my colleagues was running callgrind from the 3.2.0 release on an amd64 FC5 box and found he was encountering this assertion: valgrind: m_scheduler/scheduler.c:996 (vgPlain_scheduler): the 'impossible' happened. valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure The assertion doesn't seem to fire in a consistent location - in fact sometimes the programs runs to completion. It all seems to depend on what else is running on the machine at the same time. Instrumenting the code has shown that the problem is the floating point control word which is 0x37f at the end of the inner loop instead of the expected value of 0x27f. That corresponds to changing from double precision to double extended precision. Does anybody have any suggestions where I can go from here to track this down? Is this likely to be a kernel bug with the kernel not restoring the control word properly on a context switch? That seems very unlikely somehow but it's the only scenario I've come up with so far to explain what I'm seeing. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: <js...@ac...> - 2006-06-20 10:20:46
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-06-20 09:00:01 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 == 206 tests, 11 stderr failures, 5 stdout failures, 0 posttest 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/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/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) |
|
From: <js...@ac...> - 2006-06-20 03:00:08
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-06-20 03:30:01 BST 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 == 235 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-20 02:55:24
|
Nightly build on ford ( i686, Fedora Core 4 ) started at 2006-06-20 03:25: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 == 235 tests, 5 stderr failures, 0 stdout failures, 0 posttest 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) |
|
From: Tom H. <to...@co...> - 2006-06-20 02:45:55
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-06-20 03:30:04 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 == 237 tests, 5 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-20 02:32:34
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-06-20 03:15:01 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 == 236 tests, 19 stderr failures, 0 stdout failures, 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-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/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-20 02:30:41
|
Nightly build on ginetta ( i686, Red Hat 8.0 ) started at 2006-06-20 03:10:09 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 == 236 tests, 6 stderr failures, 0 stdout failures, 0 posttest failures == 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/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-20 02:28:46
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-06-20 03:10:09 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 == 260 tests, 2 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-06-20 02:20:52
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-06-20 03:00: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 == 260 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) |