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
(11) |
2
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Nicholas N. <nj...@ca...> - 2004-07-11 18:19:18
|
Hi, In vg_transtab.c, line 393, there's a #if'd out branch. It seems to be putting parts of the translation table into files, which seems like it might be a useful debugging aid, but I don't know how to read the files (they're binary) and there's no comment. Can someone explain? Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-11 18:17:11
|
CVS commit by nethercote:
Update VG_(mmap)() in #if'd out branch.
M +1 -1 vg_transtab.c 1.29
--- valgrind/coregrind/vg_transtab.c #1.28:1.29
@@ -401,5 +401,5 @@ Int maybe_commission_sector ( void )
//VG_(unlink)(buf);
VG_(do_syscall)(__NR_ftruncate, fd, PGROUNDUP(vg_tc_sector_szB));
- vg_tc[s] = VG_(mmap)(0, PGROUNDUP(vg_tc_sector_szB), VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC, VKI_MAP_SHARED, fd, 0);
+ vg_tc[s] = VG_(mmap)(0, PGROUNDUP(vg_tc_sector_szB), VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC, VKI_MAP_SHARED, 0, fd, 0);
VG_(close)(fd);
#endif
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-11 18:12:40
|
CVS commit by nethercote:
Add some more assertion checking where it was lacking.
M +9 -6 vg_mylibc.c 1.80
--- valgrind/coregrind/vg_mylibc.c #1.79:1.80
@@ -406,10 +406,13 @@ void* VG_(brk) ( void* end_data_segment
if (brkpage != endpage) {
- if (brkpage > endpage)
- munmap_inner((void *)brkpage, brkpage-endpage);
- else
- mmap_inner((void *)brkpage, endpage-brkpage,
+ if (brkpage > endpage) {
+ Int res = munmap_inner((void *)brkpage, brkpage-endpage);
+ vg_assert(0 == res);
+ } else {
+ Addr res = mmap_inner((void *)brkpage, endpage-brkpage,
VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC,
VKI_MAP_FIXED|VKI_MAP_PRIVATE|VKI_MAP_ANONYMOUS, -1, 0);
+ vg_assert((Addr)-1 != res);
+ }
}
VG_(curbrk) = (Char *)__curbrk = end_data_segment;
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-11 18:02:17
|
CVS commit by nethercote:
Removed some code from VG_(client_alloc)() that could be left to VG_(mmap)().
Added a comment about stack extension failure.
M +8 -13 vg_memory.c 1.58
M +8 -0 vg_scheduler.c 1.156
--- valgrind/coregrind/vg_memory.c #1.57:1.58
@@ -681,18 +681,13 @@ Addr VG_(client_alloc)(Addr addr, UInt l
len = PGROUNDUP(len);
- if (!(sf_flags & SF_FIXED))
- addr = VG_(find_map_space)(addr, len, True);
-
- // Don't do the mapping if we couldn't find space!
- if (0 == addr)
- return 0;
+ sk_assert(!(sf_flags & SF_FIXED));
+ sk_assert(0 == addr);
- if (VG_(mmap)((void *)addr, len, prot,
- VKI_MAP_FIXED | VKI_MAP_PRIVATE | VKI_MAP_ANONYMOUS | VKI_MAP_CLIENT,
- sf_flags | SF_CORE, -1, 0) == (void *)addr)
- {
+ addr = (Addr)VG_(mmap)((void *)addr, len, prot,
+ VKI_MAP_PRIVATE | VKI_MAP_ANONYMOUS | VKI_MAP_CLIENT,
+ sf_flags | SF_CORE, -1, 0);
+ if ((Addr)-1 != addr)
return addr;
- }
-
+ else
return 0;
}
--- valgrind/coregrind/vg_scheduler.c #1.155:1.156
@@ -1942,4 +1942,12 @@ void do__apply_in_new_thread ( ThreadId
VKI_PROT_READ|VKI_PROT_WRITE|VKI_PROT_EXEC,
SF_STACK);
+ // Given the low number of threads Valgrind can handle, stack
+ // allocation should pretty much always succeed, so having an
+ // assertion here isn't too bad. However, probably better would be
+ // this:
+ //
+ // if (0 == new_stack)
+ // SET_PTHREQ_RETVAL(parent_tid, -VKI_EAGAIN);
+ //
vg_assert(0 != new_stack);
VG_(threads)[tid].stack_base = new_stack;
|
|
From: Tom H. <th...@cy...> - 2004-07-11 16:58:18
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sun, 11 Jul 2004, Tom Hughes wrote:
>
> > I can work around that by marking the segments which are not mapped so
> > that I know I need to pad them, but it turns out the VG_(brk) doesn't
> > update the segment list which it gives out memory and I've far been
> > unable to make it do so as it just seems to either segfault or get into
> > an infinite loop.
>
> Hmm, sounds like there's some interaction here with my embryonic layout
> changes... for example, I've got rid of VG_(brk) by merging Valgrind's
> heap and its mmap-segment, and I want to merge that with the shadow memory
> area...
Probably. It turns out that the reason for the infinite loop if you
try and make VG_(brk) register the memory it allocates with the segment
list is that the segment list code tries to allocate a new skip list
node which winds up calling VG_(brk) again to get memory and hence you
wind up in an infinite loop.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-11 16:49:48
|
On Sun, 11 Jul 2004, Tom Hughes wrote: > I can work around that by marking the segments which are not mapped so > that I know I need to pad them, but it turns out the VG_(brk) doesn't > update the segment list which it gives out memory and I've far been > unable to make it do so as it just seems to either segfault or get into > an infinite loop. > > I've cludged around that for now, but now I find that the kernel is > choosing to allocate the io_setup page at the top of the client address > space, immediately below the client stack, thus stopping it from being > extended! > > So it looks like I will have to pad the client address space as well > in order to control where the kernel puts that page... Hmm, sounds like there's some interaction here with my embryonic layout changes... for example, I've got rid of VG_(brk) by merging Valgrind's heap and its mmap-segment, and I want to merge that with the shadow memory area... N |
|
From: Tom H. <th...@cy...> - 2004-07-11 11:11:47
|
In message <1089150608.3089.1.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2004-07-05 at 08:47 +0100, Tom Hughes wrote:
> > I agree that it's pretty braindead. In fact older versions of libaio
> > don't seem to peek at the memory in this way, but the fact that it is
> > mapped in user space suggests that it was always intended.
>
> Well, I think the practical solution is to do what we do to convince ld.
> so to put things in the right place: pad the Valgrind portion of the
> address space before the io_setup, and remove the padding afterwards.
> That will force io_setup to allocate its mapping in the client address
> space.
I've been working on this, and it's certainly fun...
The first problem I ran into was that the space from valgrind_mmap_end
to valgrind_end is all in the segment list regardless of whether or not
it has anything mapped at the kernel level. I think this is to stop
valgrind using it for memory mapping.
I can work around that by marking the segments which are not mapped so
that I know I need to pad them, but it turns out the VG_(brk) doesn't
update the segment list which it gives out memory and I've far been
unable to make it do so as it just seems to either segfault or get into
an infinite loop.
I've cludged around that for now, but now I find that the kernel is
choosing to allocate the io_setup page at the top of the client address
space, immediately below the client stack, thus stopping it from being
extended!
So it looks like I will have to pad the client address space as well
in order to control where the kernel puts that page...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <js...@ac...> - 2004-07-11 02:58:01
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-11 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow memcheck/tests/overlap (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/pushfpopf (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/tronical (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-07-11 02:25:10
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-11 03:20:01 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 ---------------------------------------- == 173 tests, 7 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/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-11 02:19:22
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-11 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 173 tests, 7 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/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-11 02:13:14
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-11 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 173 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-11 02:08:21
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-11 03:05:02 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 ---------------------------------------- == 173 tests, 7 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-11 02:07:17
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-11 03:00:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile 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 ---------------------------------------- == 173 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |