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: Jeremy F. <je...@go...> - 2004-09-01 08:36:08
|
On Tue, 2004-08-31 at 23:50 +0100, Nicholas Nethercote wrote: > P2. For kernels with "overcommit" mmapping off -- which prevents a process > from allocating more address space than the available swap space -- you > need at least 1.5GB of swap for Memcheck to run, because swap must be at > least as large as any individual segment. (And I think users with ulimit -v > set suffer the same problem.) > > S2. Avoiding this requires not using the big-bang shadow allocation > method, and that shadow memory instead be done incrementally. (More about > that below.) Does MAP_NORESERVE work? I'm not sure that incremental mmaping is enough in all circumstances, because you're trying to work around heuristics the kernel applies to allocations. MAP_NORESERVE simply tells the kernel that it shouldn't apply any heuristics to this allocation. If you have strict overcommit enabled, then there's no choice but to have enough swap - it assumes you're going to use every byte you map. > ----------------------------------------------------------------------------- > P3. Machines with small user spaces (eg. 2G:2G machines) cannot run > Memcheck, because the big shadow memory region covers 0x40000000, which > is where normal programs want to put their shadow maps. Shadow maps? Do you mean something else? Client mapbase? We can put that somewhere else (put it high, and allocate mappings growing down, for example). > S3. Fixing this requires that the boundary between client and Valgrind > is not fixed, which requires incremental shadow memory allocation. > > ----------------------------------------------------------------------------- > P4. Tools sometimes run out of address space when there is still address > space in other regions free. > > S4. The rigidity of the client/shadow-mem/valgrind division must be > reduced to fix this. > > ----------------------------------------------------------------------------- > P5. Large executables (eg. 200MB+) cannot be loaded in memory by > Valgrind in order to read their debug info. > > S5. Two possible fixes: > - make client/shadow-mem/valgrind divisions less rigid > - incremental debug info reading (but that's impossible for stabs) Well, even for stabs there's no need to mmap the whole thing in; if we just read (or mmaped) chunks at a time and processed them serially, we can extract everything needed. > ----------------------------------------------------------------------------- > Discussion > ----------------------------------------------------------------------------- > P1 can be solved independently of the others, and uncontroversially. > > P2--P5 are all related. For 32-bit machines, big-bang shadow memory > allocation does not seem appropriate -- the size of the map required > causes P2. The resulting rigidity of the address space causes P3--P5. > > The downside of switching to incremental shadow memory is that it makes > direct-offset shadow addressing impossible, at least on 32-bit. > Direct-offset seems much more plausible on 64-bit, where we have more > address to play with. But the benefits of direct-offset still are not > clear (Jeremy's experiments didn't show a speed improvement), and we don't > have any 64-bit ports working yet. The trouble is that memcheck&co do have a fixed ratio of shadow memory to real memory used. If the client uses its address space sparsely then it causes sparse (wasteful) use of the shadow memory, but since we get to place all the mmaps, we needn't make it have sparse memory use. The exception is if the client explicitly places its mappings, but I don't think that's common. So I know that people are running into memory problems, but it isn't clear to me that we can't solve them by using the address space more densely. Tools which don't have a fixed ratio (cachegrind) are another issue. They're not, technically, using shadow memory (since there isn't the 1:1 relationship between client addresses and shadow addresses), but Valgrind heap. > > ----------------------------------------------------------------------------- > Solution > ----------------------------------------------------------------------------- > A couple of steps: > > - Don't use big-bang allocation for shadow memory. Make shadow memory > maps allocated just like any other Valgrind/tool memory. Thus > Valgrind would have a single region for itself, instead of two > separate ones. This would solve P2, P4 and P5. > > - Make the client/valgrind division movable. Client memory would grow > up, Valgrind memory would grow down. This would largely solve P3. > > Only question here is: where does the stack go? If the stack size is > ulimited (eg. to 8MB), there's little problem. Otherwise, perhaps > below client_mapbase, so it grows down towards the upward-growing > heap. [nb: what happens if they collide? undefined?] We could put the stack below the executable. The x86 ABI allows this (and Solaris x86 does this). It could break some programs which assume the stack is high, but most won't care. J |
|
From: Tom H. <th...@cy...> - 2004-09-01 07:31:22
|
CVS commit by thughes: Move the include of linux/fs.h before the include of sys/un.h as the latter includes string.h on some older systems which then causes problems when linux/fs.h includes linux/string.h due to it turning various string functions into pre-processor macros. This was the problem behind bug #87820 which actually had nothing to do with gcc 2.95 and everything to do with the glibc and kernel headers that the system had installed. M +1 -1 vg_unsafe.h 1.34 --- valgrind/coregrind/vg_unsafe.h #1.33:1.34 @@ -42,4 +42,5 @@ #define _LINUX_TIME_H #endif +#include <linux/fs.h> /* for filing system ioctls */ #include <linux/net.h> /* for the SYS_* constants */ #include <sys/resource.h> /* for struct rlimit */ @@ -66,5 +67,4 @@ #include <linux/hdreg.h> /* for hard drive ioctls */ #include <linux/netlink.h>/* Some systems need this for linux/fs.h */ -#include <linux/fs.h> /* for filing system ioctls */ #ifdef HAVE_LINUX_FB_H #include <linux/fb.h> /* for fb_* structs */ |
|
From: Tom H. <th...@cy...> - 2004-09-01 07:29:14
|
CVS commit by thughes:
Make some of the parallel port ioctls conditional as older systems
don't have them defined.
M +20 -0 vg_syscalls.c 1.132
--- valgrind/coregrind/vg_syscalls.c #1.131:1.132
@@ -3411,28 +3411,38 @@ PRE(ioctl)
sizeof(int) );
break;
+#ifdef PPGETMODE
case PPGETMODE:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETMODE)", arg3,
sizeof(int) );
break;
+#endif
case PPSETPHASE:
SYSCALL_TRACK( pre_mem_read, tid, "ioctl(PPSETPHASE)", arg3,
sizeof(int) );
break;
+#ifdef PPGETPHASE
case PPGETPHASE:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETPHASE)", arg3,
sizeof(int) );
break;
+#endif
+#ifdef PPGETMODES
case PPGETMODES:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETMODES)", arg3,
sizeof(unsigned int) );
break;
+#endif
+#ifdef PPSETFLAGS
case PPSETFLAGS:
SYSCALL_TRACK( pre_mem_read, tid, "ioctl(PPSETFLAGS)", arg3,
sizeof(int) );
break;
+#endif
+#ifdef PPGETFLAGS
case PPGETFLAGS:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPGETFLAGS)", arg3,
sizeof(int) );
break;
+#endif
case PPRSTATUS:
SYSCALL_TRACK( pre_mem_write, tid, "ioctl(PPRSTATUS)", arg3,
@@ -3929,5 +3939,7 @@ POST(ioctl)
case PPSETMODE:
case PPSETPHASE:
+#ifdef PPSETFLAGS
case PPSETFLAGS:
+#endif
case PPWDATA:
case PPWCONTROL:
@@ -3938,16 +3950,24 @@ POST(ioctl)
case PPSETTIME:
break;
+#ifdef PPGETMODE
case PPGETMODE:
VG_TRACK( post_mem_write, arg3, sizeof(int) );
break;
+#endif
+#ifdef PPGETPHASE
case PPGETPHASE:
VG_TRACK( post_mem_write, arg3, sizeof(int) );
break;
+#endif
+#ifdef PPGETMODES
case PPGETMODES:
VG_TRACK( post_mem_write, arg3, sizeof(unsigned int) );
break;
+#endif
+#ifdef PPGETFLAGS
case PPGETFLAGS:
VG_TRACK( post_mem_write, arg3, sizeof(int) );
break;
+#endif
case PPRSTATUS:
VG_TRACK( post_mem_write, arg3, sizeof(unsigned char) );
|
|
From: Paul M. <pa...@sa...> - 2004-09-01 04:13:04
|
I have packaged up a version of my PPC port that corresponds to the 2.2.0 release of Valgrind. The tarball is at: http://ozlabs.org/~paulus/valgrind-2.2.0-ppc.tar.bz2 Could someone please update the web pages at valgrind.kde.org in the places where my PPC port is mentioned to point to the new tarball? On the `Related Projects' page, the dot point about not supporting Altivec instructions is no longer true, so please remove that. Thanks, Paul. |
|
From: Tom H. <th...@cy...> - 2004-09-01 03:14:19
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-09-01 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline insn_basic: valgrind -q ./../../none/tests/insn_basic insn_cmov: valgrind -q ./../../none/tests/insn_cmov insn_fpu: valgrind -q ./../../none/tests/insn_fpu insn_mmx: valgrind -q ./../../none/tests/insn_mmx insn_mmxext: valgrind -q ./../../none/tests/insn_mmxext insn_sse: valgrind -q ./../../none/tests/insn_sse malloc1: valgrind -q ./malloc1 malloc2: valgrind -q ./malloc2 Could not read `malloc2.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-09-01 02:56:03
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-09-01 03:50:00 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 ---------------------------------------- == 174 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-09-01 02:25:17
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-09-01 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-01 02:20:57
|
Nightly build on audi ( Red Hat 9 ) started at 2004-09-01 03:15:03 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-01 02:13:29
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-09-01 03:10:03 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-01 02:08:18
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-09-01 03:05:02 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 |
|
From: Eric E. <eri...@fr...> - 2004-09-01 01:03:40
|
Few ideas as they come, if they can help:
1. We can finely take control of all the memory space
by mapping everything available using MAP_NORESERVE.
If the client requires some space, we decide where we want
it to be mapped, unmap the reserved zone, and do the syscall.
The kernel won't have any other choice than mapping to the
zone we have freed, since it'll be the only zone available.
2. Run-time test is the only solution if we want to be sure
it works on all situations. Furthermore it is mandatory
for binary distributions. We have the means to do it,
with either the shmat trick or the previous reserving solution.
3. Not sure we can do that, but maybe PIE is not mandatory.
Can we have stage2 compiled only as PIC, mmap it where we
need, and perform the relocations ? I've tried a bit PIE,
and I feel it is not always working; testing for platforms
on which it works could become a nightmare.... But I'm not
an ld expert...
> P2. For kernels with "overcommit" mmapping off -- which prevents a
> process from allocating more address space than the available swap space
What are these kernels doing exactly ? Can't we reserve the space with
MAP_NORESERVE, and when we really need to use it, remap normally ?
If not possible, we can probably reserve the ranges using shm mappings.
> P5. Large executables (eg. 200MB+) cannot be loaded in memory by
> Valgrind in order to read their debug info.
>
> S5. Two possible fixes:
> - make client/shadow-mem/valgrind divisions less rigid
> - incremental debug info reading (but that's impossible for stabs)
Indeed there are other solutions. We are likely to always find
someone which will have an exe bigger than the space we have available...
Either:
- delegate dbginf reading to another process which has more free space;
communicate through ipc/whatever
- do not read the dbginfs. Have it done by another process
doing the post-processing (and filtering) of the vg results after
- recommend using dwarf2 instead of stabs, and make the reader incremental
- say concerned users to buy 64bit boxes (hummmm.....)
> The downside of switching to incremental shadow memory is that it makes
> direct-offset shadow addressing impossible, at least on 32-bit.
I wouldn't be so categoric. We can certainly do a big-bang _reservation_
(not allocation), using either MAP_NORESERVE or shm mappings, and
incrementally remap parts as we need them.
> Only question here is: where does the stack go? If the stack size is
> ulimited (eg. to 8MB), there's little problem. Otherwise, perhaps
> below client_mapbase, so it grows down towards the upward-growing
> heap. [nb: what happens if they collide? undefined?]
Wherever they are, if whatever collides, valgrind should issue
a precise error message, and provide a command-line argument so the
users can ask to reserve e.g. 256Mb of stack. I think it is safe
to have a default, relatively limited, maximum stack size, so
stack overflows could be detected quite quickly.
Cheers
--
Eric
|