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
(26) |
2
(35) |
3
(18) |
4
(14) |
|
5
(12) |
6
(13) |
7
(11) |
8
(15) |
9
(8) |
10
(13) |
11
(25) |
|
12
(13) |
13
(24) |
14
(7) |
15
(6) |
16
(8) |
17
(6) |
18
(7) |
|
19
(8) |
20
(7) |
21
(5) |
22
(7) |
23
(6) |
24
(7) |
25
(6) |
|
26
(7) |
27
(7) |
28
(5) |
29
(5) |
30
(5) |
|
|
|
From: Julian S. <js...@ac...> - 2004-09-12 23:25:40
|
Tom, Nick, Thanks for tracking this one down and fixing it. I'm not clear what the root cause of the problem was (which set of changes yesterday caused it?) and in particular whether the fix needs to be done also on _2_2_0_BRANCH ? J On Sunday 12 September 2004 22:11, Tom Hughes wrote: > In message <Pin...@he...> > > Nicholas Nethercote <nj...@ca...> wrote: > > On Sun, 12 Sep 2004, Julian Seward wrote: > > > Friday night's build went as usual on SuSE 9.1. However, last > > > night's build produces a memcheck which eats all the memory and > > > swap and thrashes the machine to hell, even with trivial progs > > > (ls). Furthermore, this message appears at startup: > > > > > > Warning: set address range perms: large range 2147483647, a 1, v 1 > > > > > > and it didn't used to. > > > > Oh yeah, I forgot to say: it's almost certainly a call to ban_mem_stack > > or die_mem_stack with a -1 argument... > > Yep. I've found the problem - it wasn't happening for me because I have > an 8Mb stack limit set in my environment. I'll commit a fix shortly. > > Tom |
|
From: Tom H. <th...@cy...> - 2004-09-12 22:49:08
|
CVS commit by thughes:
Only mark the section of the stack that has actually been used as
off limits otherwise we can try and invalidate a vast area of memory
if there is no stack limit.
M +4 -2 vg_scheduler.c 1.183
--- valgrind/coregrind/vg_scheduler.c #1.182:1.183
@@ -1248,9 +1248,11 @@ static
void cleanup_after_thread_exited ( ThreadId tid, Bool forcekill )
{
+ Segment *seg;
+
vg_assert(is_valid_or_empty_tid(tid));
vg_assert(VG_(threads)[tid].status == VgTs_Empty);
/* Its stack is now off-limits */
- VG_TRACK( die_mem_stack, VG_(threads)[tid].stack_base,
- VG_(threads)[tid].stack_size );
+ seg = VG_(find_segment)( VG_(threads)[tid].stack_base );
+ VG_TRACK( die_mem_stack, seg->addr, seg->len );
VGA_(cleanup_thread)( &VG_(threads)[tid].arch );
|
|
From: Tom H. <th...@cy...> - 2004-09-12 21:11:16
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sun, 12 Sep 2004, Julian Seward wrote:
>
> > Friday night's build went as usual on SuSE 9.1. However, last
> > night's build produces a memcheck which eats all the memory and
> > swap and thrashes the machine to hell, even with trivial progs
> > (ls). Furthermore, this message appears at startup:
> >
> > Warning: set address range perms: large range 2147483647, a 1, v 1
> >
> > and it didn't used to.
>
> Oh yeah, I forgot to say: it's almost certainly a call to ban_mem_stack
> or die_mem_stack with a -1 argument...
Yep. I've found the problem - it wasn't happening for me because I have
an 8Mb stack limit set in my environment. I'll commit a fix shortly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-12 20:43:39
|
On Sun, 12 Sep 2004, Julian Seward wrote: > Friday night's build went as usual on SuSE 9.1. However, last > night's build produces a memcheck which eats all the memory and > swap and thrashes the machine to hell, even with trivial progs > (ls). Furthermore, this message appears at startup: > > Warning: set address range perms: large range 2147483647, a 1, v 1 > > and it didn't used to. Oh yeah, I forgot to say: it's almost certainly a call to ban_mem_stack or die_mem_stack with a -1 argument... > I've been looking through Saturday's commits, trying to figure out > how this happened. One possibility is vg_mylibc.c:1.90 > (Fix minor off-by-one error), althought that doesn't seem very likely. No, not likely; that only affected an assertion that has no side effects. N |
|
From: Nicholas N. <nj...@ca...> - 2004-09-12 20:40:49
|
On Sun, 12 Sep 2004, Julian Seward wrote: > Friday night's build went as usual on SuSE 9.1. However, last > night's build produces a memcheck which eats all the memory and > swap and thrashes the machine to hell, even with trivial progs > (ls). Furthermore, this message appears at startup: > > Warning: set address range perms: large range 2147483647, a 1, v 1 > > and it didn't used to. > > Strangely, Tom's nightly builds appear OK, except "standard" (RH 7.2); > not sure if that failure is related or not. > > I've been looking through Saturday's commits, trying to figure out > how this happened. One possibility is vg_mylibc.c:1.90 > (Fix minor off-by-one error), althought that doesn't seem very likely. > > Another one which might somehow mess with memory layout is Tom's > fix to #73818 (stack rlimit stuff). Presumably either I or Tom introduced this yesterday, since we were the only ones making changes. I looked through my commits but couldn't see anything. It's hard to know without knowing which revision caused it. I realise it's a pain diagnosing someone else's breakage, but could you try to work this out? We can't really get anywhere without knowing that. You can use the -D option to checkout trees for a particular time, so for each commit you could checkout before and after the time of the commit, and see if both work ok. N |
|
From: Tom H. <th...@cy...> - 2004-09-12 12:30:17
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Strangely, Tom's nightly builds appear OK, except "standard" (RH 7.2);
> not sure if that failure is related or not.
That's been going on for a while, but it always works fine when
run by hand so I think it's something odd going on when it runs
from cron overnight.
> Another one which might somehow mess with memory layout is Tom's
> fix to #73818 (stack rlimit stuff).
>
> I have a vague memory from writing the leak checker, that SuSE
> kernels behave differently, in that they will just extend the
> stack downwards indefinitely (or something) if you endlessly prod
> just below %esp, so perhaps that's related.
All kernels work like that, and so does valgrind. The stack segment
for the main thread had SG_GROWSDOWN set and when valgrind see a
segmentation fault below the current base of that segment it extends
it and maps some more memory.
All I did was make valgrind stop doing that once the stack limit is
hit, which is exactly what the kernel will do.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-09-12 11:34:02
|
Friday night's build went as usual on SuSE 9.1. However, last night's build produces a memcheck which eats all the memory and swap and thrashes the machine to hell, even with trivial progs (ls). Furthermore, this message appears at startup: Warning: set address range perms: large range 2147483647, a 1, v 1 and it didn't used to. Strangely, Tom's nightly builds appear OK, except "standard" (RH 7.2); not sure if that failure is related or not. I've been looking through Saturday's commits, trying to figure out how this happened. One possibility is vg_mylibc.c:1.90 (Fix minor off-by-one error), althought that doesn't seem very likely. Another one which might somehow mess with memory layout is Tom's fix to #73818 (stack rlimit stuff). I have a vague memory from writing the leak checker, that SuSE kernels behave differently, in that they will just extend the stack downwards indefinitely (or something) if you endlessly prod just below %esp, so perhaps that's related. Anyone have any ideas? J |
|
From: <js...@ac...> - 2004-09-12 06:41:34
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-09-12 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow metadata: valgrind -q ./metadata mismatches: valgrind -q ./mismatches mmaptest: valgrind -q ./mmaptest nanoleak: valgrind --leak-check=yes -q ./nanoleak nanoleak_supp: valgrind --leak-check=yes --suppressions=nanoleak.supp -q ./nanoleak new_nothrow: valgrind -q ./new_nothrow new_override: valgrind ./new_override *** new_override failed (stderr) *** null_socket: valgrind -q ./null_socket overlap: valgrind -q ./overlap pth_once: valgrind -q ./../../corecheck/tests/pth_once pushfpopf: valgrind -q ./pushfpopf realloc1: valgrind -q ./realloc1 realloc2: valgrind -q ./realloc2 realloc3: valgrind -q ./realloc3 sigaltstack: valgrind -q ./sigaltstack signal2: valgrind -q ./signal2 supp1: valgrind --suppressions=supp.supp -q ./supp1 supp2: valgrind --suppressions=supp.supp -q ./supp2 suppfree: valgrind -q ./suppfree |
|
From: Tom H. <th...@cy...> - 2004-09-12 03:07:39
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-09-12 02:00:07 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fork: valgrind -q ./fork fpu_lazy_eflags: valgrind ./fpu_lazy_eflags fucomip: valgrind ./fucomip gxx304: valgrind ./gxx304 insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse int: valgrind ./int map_unmap: valgrind ./map_unmap mq: valgrind ./mq mremap: valgrind ./mremap munmap_exe: valgrind ./munmap_exe pth_blockedsig: valgrind ./pth_blockedsig pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert Could not read `rcl_assert.stderr.exp' make: *** [regtest] Error 2 |
|
From: Tom H. <to...@co...> - 2004-09-12 02:25:24
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-09-12 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-12 02:19:40
|
Nightly build on audi ( Red Hat 9 ) started at 2004-09-12 03:15:04 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-12 02:13:31
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-09-12 03:10:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-09-12 02:09:13
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-09-12 03:05:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 179 tests, 14 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/brk2 (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/mismatches (stderr) memcheck/tests/new_nothrow (stderr) memcheck/tests/new_override (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) none/tests/coolo_sigaction (stderr) none/tests/gxx304 (stderr) make: *** [regtest] Error 1 |