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
(8) |
2
(11) |
3
(21) |
4
(15) |
5
(10) |
|
6
(7) |
7
(7) |
8
(5) |
9
(7) |
10
(5) |
11
(1) |
12
(21) |
|
13
(8) |
14
(17) |
15
(6) |
16
(10) |
17
(7) |
18
(6) |
19
(15) |
|
20
(12) |
21
(16) |
22
(25) |
23
(14) |
24
(10) |
25
(7) |
26
(6) |
|
27
(34) |
28
(13) |
29
(10) |
30
(8) |
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-06-29 17:09:42
|
On Tue, 2004-06-29 at 09:49 +0100, Nicholas Nethercote wrote: > Hmm, on one hand I agree, but on the other hand I'm not so sure -- sinc= e=20 > we are using our own vg_assert() which is never turned off... how would= a=20 > new syscall-retval-checking function be any different, other than not=20 > having "assert" in the name? I guess the short question is: what's the= =20 > definition of "assert-style"? Well, something with "assert" in the name. I would say that anything with assert in the name is expected to behave like assert(), even if we don't intend to allow it to be disabled. But aside from that, we should give more useful messages if we fail from out of memory. > VG_(client_alloc) was being used for: > - new thread stacks > - client malloc() >=20 > It wasn't being used (VG_(mmap)(VKI_MAP_CLIENT) was) for > - client brk() > - extending stacks But those are distinct operations. The former is placing an allocation at some arbitrary location in the client address space, whereas the latter are mapping memory at very specific places. > I'd also like PRE(mmap) and PRE(munmap) to call VG_(mmap) and VG_(munma= p)=20 > rather than working stuff out for themselves, since the actions in both= =20 > function pairs is basically the same; the main obstacle for this is=20 > *%^$=C2=A3! mremap(), but I could move much of PRE(mremap)'s workings i= nto=20 > VG_(mremap). Then the only functions working directly with the=20 > segment-list (eg. find_map_space, map_segment, unmap_range) would be=20 > VG_(mmap), VG_(munmap), and main(). Cool, it would be nice to unify these. I seem to remember there were some subtleties (aren't there ever), but it should be OK. The plan I've had in the back of my mind for allocation is to expose memory-allocating functions (specifically, malloc, calloc, realloc, free, new, delete, mmap, munmap and maybe brk/sbrk) so that 1) we can use them internally (maybe) and 2) third-party libraries can use them. I think we could get a lot of power from moving to C++ as an implementation language, and a lot of the stuff in the STL is a good match for what we're doing. Memory isn't the only problem for using 3rd-party libraries - we have to worry about all the other resources they can allocate. For example, if a library creates a file-descriptor, we need to make sure its out of reach of the client range. I've been thinking about completely virtualizing the FD namespace for clients, but I think that's a lot of complexity for not much gain. So the question is still open. J |
|
From: Nicholas N. <nj...@ca...> - 2004-06-29 15:07:13
|
On Tue, 29 Jun 2004, Nicholas Nethercote wrote: > You're right about the heap; I stumbled across the startup delicacy > involving it pretty quickly. Without it, there's a real bootstrapping > problem, in that V needs the segment list initialised before it can allocate > any memory for itself, but it also needs to allocate memory in order to > initialise the segment list. That's why I've done this partial overhaul > rather than the full thing, because I can't see how it can be done easily. I've worked out how to do this now. The solution is only mildly hacky -- the first superblock allocated by newSuperblock() is now done not with a mapping, but with a static block. This gives the startup code enough memory to play with in order to set up the segment list, and safely start allocating with VG_(mmap). I've got checking in place to ensure that this all works as it should (eg. that the static block is big enough, and that the segment-list-initialisation code is responsible for the first allocations). Using this, I've been able to remove VG_(brk) and Valgrind's heap, and am doing all V's allocations in its map-seg-area. So far, so good. Currently V itself (stage2) is always mapped at 0xb8000000 which is sucky (this is the 'kickstart_base' value). In my new version I'm putting it at 0xbf000000, just below V's stack (libs get put lower now). But the number is still hardwired, and based around the assumption that the stack starts at 0xc0000000. I thought an install-time test that determined where the stack normally goes could be useful for systems that put the stack at eg. 0xffff0000 -- I could put stage2 a short distance before the stack, and everything is done relative to that. Another problem is the libs used by Valgrind (ld.so, libc.so, libdl.so) which get loaded before main() begins. Basically, I'd like to jam them up just below stage2, but this requires knowing how big they are, and I can't see how to do that. Any ideas? Thanks. N |
|
From: Tom H. <th...@cy...> - 2004-06-29 10:20:24
|
Nightly build on audi ( Red Hat 9 ) started at 2004-06-29 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 ---------------------------------------- == 169 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: Nicholas N. <nj...@ca...> - 2004-06-29 10:02:20
|
Hi,
vg_skiplist.c line 288:
Int size = sizeof(SkipNode) * sizeof(SkipNode *) * SK_MAXHEIGHT;
Surely that should be:
Int size = sizeof(SkipNode) + sizeof(SkipNode *) * SK_MAXHEIGHT;
?
---
While I'm looking at vg_skiplist.c... a SkipNode looks like:
struct _SkipNode {
UInt magic;
UShort level;
SkipNode *next[0];
};
There's no space for the key and value. AFAICT, they're stored before the
start of the _SkipNode struct, and the 'size' and 'keyoffset' elements of
struct _SkipList lets the code find them. The allocation points are
careful to provide this extra space, and there are functions that find the
key and value from a node. Except the head node doesn't seem to have a
key/value pair. Jeremy, is that all true? Wow, pretty nasty. It would
be nice to have a comment explaining this.
N
|
|
From: Tom H. <th...@cy...> - 2004-06-29 09:45:44
|
CVS commit by thughes:
Make VPATH builds work so that valgrind can be built in a different
directory from the source tree. This resolves bug 83040.
Based on patch from Ralf Wildenhues <Ral...@gm...>.
M +2 -1 Makefile.am 1.66
M +2 -2 addrcheck/Makefile.am 1.50
M +2 -1 auxprogs/Makefile.am 1.7
M +2 -1 cachegrind/Makefile.am 1.44
M +2 -1 corecheck/Makefile.am 1.43
M +8 -7 coregrind/Makefile.am 1.74
M +2 -1 coregrind/demangle/Makefile.am 1.12
M +2 -1 helgrind/Makefile.am 1.47
M +2 -1 lackey/Makefile.am 1.44
M +2 -1 massif/Makefile.am 1.3
M +1 -1 memcheck/Makefile.am 1.49
M +2 -1 none/Makefile.am 1.44
--- valgrind/Makefile.am #1.65:1.66
@@ -54,5 +54,6 @@
mkdir -p $(top_builddir)/.in_place
rm -f $(addprefix $(top_builddir)/.in_place/,default.supp $(SUPP_FILES))
- ln -s $(addprefix $(top_srcdir)/../,default.supp $(SUPP_FILES)) $(top_builddir)/.in_place
+ ln -s ../default.supp $(top_builddir)/.in_place
+ ln -s $(addprefix ../$(top_srcdir)/,$(SUPP_FILES)) $(top_builddir)/.in_place
distclean-local:
--- valgrind/addrcheck/Makefile.am #1.49:1.50
@@ -3,6 +3,6 @@
# include memcheck/ for mac_shared.h
-AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/memcheck \
- -DVG_LIBDIR="\"$(libdir)"\"
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -I$(top_srcdir)/memcheck -DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g
--- valgrind/auxprogs/Makefile.am #1.6:1.7
@@ -2,5 +2,6 @@
SUBDIRS = .
-AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_srcdir)/coregrind \
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -I$(top_builddir)/coregrind -I$(top_srcdir)/coregrind \
-DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -O -g
--- valgrind/cachegrind/Makefile.am #1.43:1.44
@@ -2,5 +2,6 @@
SUBDIRS = . docs tests
-AM_CPPFLAGS = -I$(top_srcdir)/include -DVG_LIBDIR="\"$(libdir)"\"
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g
--- valgrind/corecheck/Makefile.am #1.42:1.43
@@ -2,5 +2,6 @@
SUBDIRS = . tests docs
-AM_CPPFLAGS = -I$(top_srcdir)/include -DVG_LIBDIR="\"$(libdir)"\"
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g
--- valgrind/coregrind/Makefile.am #1.73:1.74
@@ -2,5 +2,6 @@
SUBDIRS = x86 demangle . docs
-add_includes = -I$(srcdir)/demangle -I$(top_srcdir)/include -I$(srcdir)/x86
+add_includes = -I$(srcdir)/demangle -I$(top_builddir)/include \
+ -I$(top_srcdir)/include -I$(srcdir)/x86
valdir = $(libdir)/valgrind
@@ -91,13 +92,13 @@
-ldl
-vg_intercept.c: $(srcdir)/gen_intercepts.pl vg_intercept.c.base
+vg_intercept.c: $(srcdir)/gen_intercepts.pl $(srcdir)/vg_intercept.c.base
rm -f $@
- $(PERL) $(srcdir)/gen_intercepts.pl < vg_intercept.c.base > $@
+ $(PERL) $(srcdir)/gen_intercepts.pl < $(srcdir)/vg_intercept.c.base > $@
-vg_replace_malloc.c: $(srcdir)/gen_intercepts.pl vg_replace_malloc.c.base
+vg_replace_malloc.c: $(srcdir)/gen_intercepts.pl $(srcdir)/vg_replace_malloc.c.base
rm -f $@
- $(PERL) $(srcdir)/gen_intercepts.pl < vg_replace_malloc.c.base > $@
+ $(PERL) $(srcdir)/gen_intercepts.pl < $(srcdir)/vg_replace_malloc.c.base > $@
-vg_toolint.c: $(srcdir)/gen_toolint.pl $(srcdir)/toolfuncs.def $(srcdir)/Makefile
+vg_toolint.c: $(srcdir)/gen_toolint.pl $(srcdir)/toolfuncs.def ./Makefile
rm -f $@
$(PERL) $(srcdir)/gen_toolint.pl callwrap < $(srcdir)/toolfuncs.def > $@ || rm -f $@
@@ -107,5 +108,5 @@
$(PERL) $(srcdir)/gen_toolint.pl structdef < $(srcdir)/toolfuncs.def >> $@ || rm -f $@
-vg_toolint.h: $(srcdir)/gen_toolint.pl $(srcdir)/toolfuncs.def $(srcdir)/Makefile
+vg_toolint.h: $(srcdir)/gen_toolint.pl $(srcdir)/toolfuncs.def ./Makefile
rm -f $@
$(PERL) $(srcdir)/gen_toolint.pl proto < $(srcdir)/toolfuncs.def > $@ || rm -f $@
--- valgrind/coregrind/demangle/Makefile.am #1.11:1.12
@@ -1,4 +1,5 @@
-AM_CPPFLAGS = -I$(top_srcdir)/coregrind -I$(top_srcdir)/include
+AM_CPPFLAGS = -I$(top_builddir)/coregrind -I$(top_srcdir)/coregrind \
+ -I$(top_builddir)/include -I$(top_srcdir)/include
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer -g
--- valgrind/helgrind/Makefile.am #1.46:1.47
@@ -2,5 +2,6 @@
SUBDIRS = . docs tests
-AM_CPPFLAGS = -I$(top_srcdir)/include -DVG_LIBDIR="\"$(libdir)"\"
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g
--- valgrind/lackey/Makefile.am #1.43:1.44
@@ -2,5 +2,6 @@
SUBDIRS = . docs tests
-AM_CPPFLAGS = -I$(top_srcdir)/include -DVG_LIBDIR="\"$(libdir)"\"
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g
--- valgrind/massif/Makefile.am #1.2:1.3
@@ -2,5 +2,6 @@
SUBDIRS = . tests docs hp2ps
-AM_CPPFLAGS = -I$(top_srcdir)/include -DVG_LIBDIR="\"$(libdir)"\"
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g
--- valgrind/memcheck/Makefile.am #1.48:1.49
@@ -2,5 +2,5 @@
SUBDIRS = . tests docs
-all_includes = -I$(top_srcdir)/include
+all_includes = -I$(top_builddir)/include -I$(top_srcdir)/include
AM_CPPFLAGS = $(all_includes) -DVG_LIBDIR="\"$(libdir)"\"
--- valgrind/none/Makefile.am #1.43:1.44
@@ -2,5 +2,6 @@
SUBDIRS = . docs tests
-AM_CPPFLAGS = -I$(top_srcdir)/include -DVG_LIBDIR="\"$(libdir)"\"
+AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include \
+ -DVG_LIBDIR="\"$(libdir)"\"
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -O -fomit-frame-pointer \
@PREFERRED_STACK_BOUNDARY@ -g
|
|
From: Tom H. <th...@cy...> - 2004-06-29 09:21:56
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-06-29 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 169 tests, 5 stderr failures, 1 stdout failure ================= 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/writev (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@ca...> - 2004-06-29 08:50:27
|
On Mon, 28 Jun 2004, Jeremy Fitzhardinge wrote:
> I'm picking through it now,
Great, thanks for having a look.
> but I remember one potential problem in
> getting rid of Valgrind's heap. There's some code in there near startup
> which "knows" that the address space range for the heap has already been
> reserved in the segment map, but the mmap area is not covered by the
> segment map. This is a pretty fragile area, because if memory gets
> allocated without being in the segment map, it will all look OK until it
> gets mmaped over...
>
> Hence the comment:
> + // Build segment map -- first, do valgrind segments only, with no
> + // symbols. This is so we know where the free space is before we sta=
rt
> + // using mmap when reading symbols, in the second stage (Nb: using he=
ap
> + // is ok before this point).
>
> Why remove this comment?
It just got moved into setup_segments_list().
You're right about the heap; I stumbled across the startup delicacy=20
involving it pretty quickly. Without it, there's a real bootstrapping=20
problem, in that V needs the segment list initialised before it can=20
allocate any memory for itself, but it also needs to allocate memory in=20
order to initialise the segment list. That's why I've done this partial=20
overhaul rather than the full thing, because I can't see how it can be=20
done easily.
> This kind of stuff is absolutely evil:
>
> @@ -1103,7 +1104,7 @@ Addr open_debug_file( Char* name, UInt c
> VG_(close)(fd);
>
> if (calc_gnu_debuglink_crc32(0, (UChar*)addr, *size) !=3D crc) {
> - VG_(munmap)((void*)addr, *size);
> + vg_assert(0 =3D=3D VG_(munmap)((void*)addr, *size));
> return 0;
> }
>
> You should *never* put an expression with side-effects into an assert-
> style statement. Perhaps we should have another kind of syscall-retval
> checker function (which could also print a useful message with the
> errno).
Hmm, on one hand I agree, but on the other hand I'm not so sure -- since=20
we are using our own vg_assert() which is never turned off... how would a=
=20
new syscall-retval-checking function be any different, other than not=20
having "assert" in the name? I guess the short question is: what's the=20
definition of "assert-style"?
> I'm not too happy about losing VG_(client_alloc/free). If we decide to
> change the way that client allocations are done, it would be useful if
> all the client allocations are coming through the same common place.
> What's the gain in dropping them?
Less code, and consistency. They weren't all coming through the same=20
place anyway.
VG_(client_alloc) was being used for:
- new thread stacks
- client malloc()
It wasn't being used (VG_(mmap)(VKI_MAP_CLIENT) was) for
- client brk()
- extending stacks
I could put them back in. But it was exactly this kind of thing I was=20
trying to get rid of -- having two ways of doing the same thing, without=20
an apparent (or documented) reason for why one was preferred in any place.=
=20
Even with my changes, the call graph is still annoyingly convoluted. I'd=
=20
still love to get rid of Valgrind's heap; AFAICT the startup delicacy is=
=20
the only compelling reason to keep it. Maybe static memory could be used=
=20
to hold segment list nodes alloc'd before VG_(mmap) is safe to use.
I'd also like PRE(mmap) and PRE(munmap) to call VG_(mmap) and VG_(munmap)=
=20
rather than working stuff out for themselves, since the actions in both=20
function pairs is basically the same; the main obstacle for this is=20
*%^$=A3! mremap(), but I could move much of PRE(mremap)'s workings into=20
VG_(mremap). Then the only functions working directly with the=20
segment-list (eg. find_map_space, map_segment, unmap_range) would be=20
VG_(mmap), VG_(munmap), and main().
Both of these desires have the same goal -- for all allocations to go via=
=20
VG_(mmap) and VG_(munmap) (and VG_(mremap), unavoidably).
Thanks for the feedback.
N |
|
From: Tom H. <to...@co...> - 2004-06-29 03:01:38
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-06-29 03:20: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 ---------------------------------------- == 169 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-06-29 02:39:54
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-06-29 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 ---------------------------------------- == 169 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-06-29 02:13:28
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-06-29 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 ---------------------------------------- == 169 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 |