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
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Julian S. <js...@ac...> - 2005-03-01 20:48:13
|
> > I vote for permanently-enabled summary only, with --leak-check=yes > > doing the full thing. > > Would you be able to turn the leak checker off? Err, I hadn't thought of that. Ok. I change my vote. Let's have --leak-check=yes|summary|no, with the default being yes, and summary ... well, just producing a summary. When =yes is in effect, we should also print a line saying "use ...=summary or ...=no to reduce the amount of output." J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-01 20:25:41
|
CVS commit by nethercote: fix typo M +1 -1 valgrind-quick-start 1.3 --- devel-home/valgrind/valgrind-quick-start #1.2:1.3 @@ -25,5 +25,5 @@ Use this command line: - valgrind --tool=memcheck --num-callers=40 --leak-check=yes myprog arg2 arg2 + valgrind --tool=memcheck --num-callers=40 --leak-check=yes myprog arg1 arg2 The --tool option invokes Memcheck. The --num-callers option asks for big |
|
From: Jeremy F. <je...@go...> - 2005-03-01 08:21:44
|
Jeremy Fitzhardinge wrote:
>CVS commit by fitzhardinge:
>
>Make it so the thread-error printing machinery noticers its her in the
>death sequence. Also: add a test case; getting more expert with knife+fork.
>
Hm, that was random...
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-01 08:20:54
|
CVS commit by fitzhardinge:
Update test results.
M +9 -7 mc_main.c 1.66
M +2 -6 tests/addressable.stderr.exp 1.2
M +2 -2 tests/clientperm.stdout.exp 1.2
M +3 -7 tests/custom_alloc.stderr.exp 1.6
M +0 -1 tests/describe-block.stderr.exp 1.2
M +14 -10 tests/mempool.stderr.exp 1.4
M +2 -4 tests/scalar.stderr.exp 1.46
--- valgrind/memcheck/tests/addressable.stderr.exp #1.1:1.2
@@ -46,14 +46,10 @@
at 0x........: test5 (addressable.c:85)
by 0x........: main (addressable.c:125)
- Address 0x........ is 10 bytes inside a block of size 20480 client-defined
- at 0x........: test5 (addressable.c:82)
- by 0x........: main (addressable.c:125)
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
Uninitialised byte(s) found during client check request
at 0x........: test5 (addressable.c:91)
by 0x........: main (addressable.c:125)
- Address 0x........ is 20 bytes inside a block of size 20480 client-defined
- at 0x........: test5 (addressable.c:82)
- by 0x........: main (addressable.c:125)
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
--- valgrind/memcheck/tests/clientperm.stdout.exp #1.1:1.2
@@ -1,4 +1,4 @@
-m_na: returned value is 0
+m_na: returned value is -1
sum is non-positive
-m_rm: returned value is 0
+m_rm: returned value is 1
sum is non-positive
--- valgrind/memcheck/tests/custom_alloc.stderr.exp #1.5:1.6
@@ -1,7 +1,6 @@
Invalid write of size 4
at 0x........: main (custom_alloc.c:79)
- Address 0x........ is 48 bytes inside a block of size 100000 client-defined
- at 0x........: get_superblock (custom_alloc.c:25)
- by 0x........: custom_alloc (custom_alloc.c:40)
+ Address 0x........ is 0 bytes after a block of size 40 alloc'd
+ at 0x........: custom_alloc (custom_alloc.c:47)
by 0x........: main (custom_alloc.c:76)
@@ -20,6 +19,3 @@
Invalid read of size 4
at 0x........: main (custom_alloc.c:89)
- Address 0x........ is 8 bytes inside a block of size 100000 client-defined
- at 0x........: get_superblock (custom_alloc.c:25)
- by 0x........: custom_alloc (custom_alloc.c:40)
- by 0x........: main (custom_alloc.c:76)
+ Address 0x........ is not stack'd, malloc'd or (recently) free'd
--- valgrind/memcheck/tests/describe-block.stderr.exp #1.1:1.2
@@ -1,4 +1,3 @@
-Thread 1:
Invalid write of size 1
at 0x........: main (describe-block.c:6)
--- valgrind/memcheck/tests/mempool.stderr.exp #1.3:1.4
@@ -2,7 +2,8 @@
at 0x........: test (mempool.c:124)
by 0x........: main (mempool.c:148)
- Address 0x........ is 1 bytes before a block of size 10 client-defined
- at 0x........: allocate (mempool.c:99)
- by 0x........: test (mempool.c:115)
+ Address 0x........ is 7 bytes inside a block of size 100000 alloc'd
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: make_pool (mempool.c:38)
+ by 0x........: test (mempool.c:111)
by 0x........: main (mempool.c:148)
@@ -10,7 +11,8 @@
at 0x........: test (mempool.c:125)
by 0x........: main (mempool.c:148)
- Address 0x........ is 0 bytes after a block of size 10 client-defined
- at 0x........: allocate (mempool.c:99)
- by 0x........: test (mempool.c:115)
+ Address 0x........ is 18 bytes inside a block of size 100000 alloc'd
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: make_pool (mempool.c:38)
+ by 0x........: test (mempool.c:111)
by 0x........: main (mempool.c:148)
@@ -18,6 +20,7 @@
at 0x........: test (mempool.c:129)
by 0x........: main (mempool.c:148)
- Address 0x........ is 70 bytes inside a mempool of size 100000 client-defined
- at 0x........: make_pool (mempool.c:43)
+ Address 0x........ is 70 bytes inside a block of size 100000 alloc'd
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: make_pool (mempool.c:38)
by 0x........: test (mempool.c:111)
by 0x........: main (mempool.c:148)
@@ -26,6 +29,7 @@
at 0x........: test (mempool.c:130)
by 0x........: main (mempool.c:148)
- Address 0x........ is 96 bytes inside a mempool of size 100000 client-defined
- at 0x........: make_pool (mempool.c:43)
+ Address 0x........ is 96 bytes inside a block of size 100000 alloc'd
+ at 0x........: malloc (vg_replace_malloc.c:...)
+ by 0x........: make_pool (mempool.c:38)
by 0x........: test (mempool.c:111)
by 0x........: main (mempool.c:148)
--- valgrind/memcheck/tests/scalar.stderr.exp #1.45:1.46
@@ -2699,6 +2699,5 @@
by 0x........: __libc_start_main (in /...libc...)
by 0x........: ...
- Address 0x........ is 0 bytes inside a block of size 12 client-defined
- at 0x........: main (scalar.c:811)
+ Address 0x........ is on thread 1's stack
Syscall param sigaltstack(oss) points to unaddressable byte(s)
@@ -2706,6 +2705,5 @@
by 0x........: __libc_start_main (in /...libc...)
by 0x........: ...
- Address 0x........ is 0 bytes inside a block of size 12 client-defined
- at 0x........: main (scalar.c:811)
+ Address 0x........ is on thread 1's stack
-----------------------------------------------------
187: __NR_sendfile 4s 1m
--- valgrind/memcheck/mc_main.c #1.65:1.66
@@ -1885,6 +1885,7 @@ Bool SK_(handle_client_request) ( Thread
if (vg_cgbs == NULL
|| arg[2] >= vg_cgb_used ||
- (vg_cgbs[arg[2]].start == 0 && vg_cgbs[arg[2]].size == 0))
- return 1;
+ (vg_cgbs[arg[2]].start == 0 && vg_cgbs[arg[2]].size == 0)) {
+ *ret = 1;
+ } else {
sk_assert(arg[2] >= 0 && arg[2] < vg_cgb_used);
vg_cgbs[arg[2]].start = vg_cgbs[arg[2]].size = 0;
@@ -1892,4 +1893,5 @@ Bool SK_(handle_client_request) ( Thread
vg_cgb_discards++;
*ret = 0;
+ }
break;
|
|
From: Jeremy F. <je...@go...> - 2005-03-01 06:25:56
|
CVS commit by fitzhardinge:
Make it so the thread-error printing machinery noticers its her in the
death sequence. Also: add a test case; getting more expert with knife+fork.
A tests/describe-block.c 1.1 [no copyright]
A tests/describe-block.stderr.exp 1.1
A tests/describe-block.vgtest 1.1
M +6 -2 mac_needs.c 1.34
M +1 -0 mac_shared.h 1.35
M +49 -24 docs/mc_main.html 1.14
M +3 -0 tests/Makefile.am 1.69
--- valgrind/memcheck/mac_needs.c #1.33:1.34
@@ -108,4 +108,5 @@ void clear_AddrInfo ( AddrInfo* ai )
ai->stack_tid = VG_INVALID_THREADID;
ai->maybe_gcc = False;
+ ai->desc = NULL;
}
@@ -229,6 +230,6 @@ void MAC_(pp_AddrInfo) ( Addr a, AddrInf
case Freed: case Mallocd: case UserG: case Mempool: {
SizeT delta;
- UChar* relative;
- UChar* kind;
+ const Char* relative;
+ const Char* kind;
if (ai->akind == Mempool) {
kind = "mempool";
@@ -236,4 +237,7 @@ void MAC_(pp_AddrInfo) ( Addr a, AddrInf
kind = "block";
}
+ if (ai->desc != NULL)
+ kind = ai->desc;
+
if (ai->rwoffset < 0) {
delta = (SizeT)(- ai->rwoffset);
--- valgrind/memcheck/mac_shared.h #1.34:1.35
@@ -66,4 +66,5 @@ typedef
ExeContext* lastchange; // Freed, Mallocd
ThreadId stack_tid; // Stack
+ const Char *desc; // UserG
Bool maybe_gcc; // True if just below %esp -- could be a gcc bug.
}
--- valgrind/memcheck/tests/Makefile.am #1.68:1.69
@@ -23,4 +23,5 @@
clientperm.stdout.exp clientperm.vgtest \
custom_alloc.stderr.exp custom_alloc.vgtest \
+ describe-block.stderr.exp describe-block.vgtest \
doublefree.stderr.exp doublefree.vgtest \
error_counts.stderr.exp error_counts.stdout.exp error_counts.vgtest \
@@ -89,4 +90,5 @@
badloop badpoll badrw brk brk2 buflen_check \
clientperm custom_alloc \
+ describe-block \
doublefree error_counts errs1 exitprog execve execve2 \
fprw fwrite hello inits inline \
@@ -126,4 +128,5 @@
clientperm_SOURCES = clientperm.c
custom_alloc_SOURCES = custom_alloc.c
+describe_block_SOURCES = describe-block.c
doublefree_SOURCES = doublefree.c
error_counts_SOURCES = error_counts.c
--- valgrind/memcheck/docs/mc_main.html #1.13:1.14
@@ -41,6 +41,5 @@
yet been free'd, but to which no pointer can be found. Such a
block can never be free'd by the program, since no pointer to it
- exists. Leak checking is disabled by default because it tends
- to generate dozens of error messages. </li><br><p>
+ exists. </li><br><p>
<li><code>--show-reachable=no</code> [default]<br>
@@ -56,5 +55,8 @@
indicate memory leaks, because you do not actually have a
pointer to the start of the block which you can hand to
- <code>free</code>, even if you wanted to. </li><br><p>
+ <code>free</code>, even if you wanted to.
+
+ <p> This option also shows indirectly leaked blocks (blocks
+ which are only referenced by other leaked blocks).</li><br><p>
<li><code>--leak-resolution=low</code> [default]<br>
@@ -737,13 +739,29 @@
at exit. But many programs do.
-<p>For each such block, Memcheck scans the entire address space of the
-process, looking for pointers to the block. One of three situations
-may result:
+<p>Technically, a leak is any allocated memory which won't be used
+again. Since Valgrind can't predict the future, it defines a leak as
+memory which has no pointers to it. Your program can't ever use such
+memory.
+
+<p>To find leaked blocks, Valgrind finds all the blocks which have not
+been leaked, by searching for pointers to them. Starting from the
+"root set" (static data, thread stacks and registers), it finds each
+immediately pointed-to block, and from those all the other blocks on
+the heap.
+
+<p>Once it has found all the unleaked blocks, the remaining blocks
+must be leaked. Rather than reporting on every single leaked block
+individually, it groups them into clusters of leaked blocks: leaked
+blocks which point to other leaked blocks. The blocks which it reports
+are the "heads" of each leaked cluster.
+
+There are two kinds of references to a block in memory:
<ul>
- <li>A pointer to the start of the block is found. This usually
- indicates programming sloppiness; since the block is still
+ <li>A pointer to the start of the block is found. This might
+ indicate programming sloppiness; since the block is still
pointed at, the programmer could, at least in principle, free'd
- it before program exit.</li><br>
+ it before program exit. It could also be a real leak, if a data
+ structure is growing without bound.
<p>
@@ -753,13 +771,6 @@
block as "dubious", that is, possibly leaked,
because it's unclear whether or
- not a pointer to it still exists.</li><br>
+ not a pointer to it still exists.
<p>
-
- <li>The worst outcome is that no pointer to the block can be found.
- The block is classified as "leaked", because the
- programmer could not possibly have free'd it at program exit,
- since no pointer to it exists. This might be a symptom of
- having lost the pointer at some earlier point in the
- program.</li>
</ul>
@@ -770,8 +781,17 @@
not have any leaked or dubious blocks at exit.
-<p>The precise area of memory in which Memcheck searches for pointers
-is: all naturally-aligned 4-byte words for which all A bits indicate
+
+
+<p>The precise areas in which Memcheck searches for pointers
+in the root set are:
+<ul>
+<li>Read-write mapped segments which are not part of the heap
+<li>The stack of each living thread, above the stack pointer
+<li>Integer registers of each living thread
+</ul>
+<p>Within these areas, and within the heap, it inspects each
+naturally-aligned 4-byte word for which all A bits indicate
addressibility and all V bits indicated that the stored value is
-actually valid.
+actually valid, and checks to see if it is a valid heap pointer.
<p>
@@ -790,11 +810,16 @@
ranges as completely inaccessible, accessible but containing
undefined data, and accessible and containing defined data,
- respectively. Subsequent errors may have their faulting
- addresses described in terms of these blocks. Returns a
- "block handle". Returns zero when not run on Valgrind.
+ respectively. Returns -1 when run under Valgrind, zero when
+ not run on Valgrind.
+<p>
+<li><code>VALGRIND_CREATE_BLOCK</code>: This describes a range
+ of memory using the supplied string; this string is displayed
+ for any error which relates to that range of memory. Returns
+ a block handle which can be used with
+ <code>VALGRIND_DISCARD</code>.
<p>
<li><code>VALGRIND_DISCARD</code>: At some point you may want
Valgrind to stop reporting errors in terms of the blocks
- defined by the previous three macros. To do this, the above
+ defined by the previous macro. To do this, the above
macros return a small-integer "block handle". You can pass
this block handle to <code>VALGRIND_DISCARD</code>. After
|
|
From: Jeremy F. <je...@go...> - 2005-03-01 06:22:40
|
CVS commit by fitzhardinge:
Don't create general blocks when using VALGRIND_MAKE_* macros. Instead, add
a new VALGRIND_CREATE_BLOCK call which creates a description for a region
of memory. The VALGRIND_MAKE_* macros always return -1 under Valgrind, which
should be OK to VALGRIND_DISCARD.
M +2 -2 coregrind/vg_malloc2.c 1.36
M +27 -28 memcheck/mc_main.c 1.65
M +17 -8 memcheck/memcheck.h 1.21
--- valgrind/memcheck/memcheck.h #1.20:1.21
@@ -92,4 +92,6 @@ typedef
VG_USERREQ__SET_VBITS,
+ VG_USERREQ__CREATE_BLOCK,
+
/* This is just for memcheck's internal use - don't use it */
_VG_USERREQ__MEMCHECK_GET_RECORD_OVERLAP = VG_USERREQ_SKIN_BASE('M','C')+256
@@ -101,6 +103,5 @@ typedef
/* Mark memory at _qzz_addr as unaddressible and undefined for
- _qzz_len bytes. Returns an int handle pertaining to the block
- descriptions Valgrind will use in subsequent error messages. */
+ _qzz_len bytes. */
#define VALGRIND_MAKE_NOACCESS(_qzz_addr,_qzz_len) \
(__extension__({unsigned int _qzz_res; \
@@ -131,10 +132,18 @@ typedef
}))
-/* Discard a block-description-handle obtained from the above three
- macros. After this, Valgrind will no longer be able to relate
- addressing errors to the user-defined block associated with the
- handle. The permissions settings associated with the handle remain
- in place. Returns 1 for an invalid handle, 0 for a valid
- handle. */
+/* Create a block-description handle. The description is an ascii
+ string which is included in any messages pertaining to addresses
+ within the specified memory range. Has no other effect on the
+ properties of the memory range. */
+#define VALGRIND_CREATE_BLOCK(_qzz_addr,_qzz_len, _qzz_desc) \
+ (__extension__({unsigned int _qzz_res; \
+ VALGRIND_MAGIC_SEQUENCE(_qzz_res, 0 /* default return */, \
+ VG_USERREQ__CREATE_BLOCK, \
+ _qzz_addr, _qzz_len, _qzz_desc, 0); \
+ _qzz_res; \
+ }))
+
+/* Discard a block-description-handle. Returns 1 for an
+ invalid handle, 0 for a valid handle. */
#define VALGRIND_DISCARD(_qzz_blkindex) \
(__extension__ ({unsigned int _qzz_res; \
--- valgrind/memcheck/mc_main.c #1.64:1.65
@@ -1684,9 +1684,7 @@ void SK_(print_debug_usage)(void)
an empty slot at allocation time. This in turn means allocation is
relatively expensive, so we hope this does not happen too often.
-*/
-typedef
- enum { CG_NotInUse, CG_NoAccess, CG_Writable, CG_Readable }
- CGenBlockKind;
+ An unused block has start == size == 0
+*/
typedef
@@ -1695,5 +1693,5 @@ typedef
SizeT size;
ExeContext* where;
- CGenBlockKind kind;
+ Char* desc;
}
CGenBlock;
@@ -1721,5 +1719,5 @@ Int vg_alloc_client_block ( void )
for (i = 0; i < vg_cgb_used; i++) {
vg_cgb_search++;
- if (vg_cgbs[i].kind == CG_NotInUse)
+ if (vg_cgbs[i].start == 0 && vg_cgbs[i].size == 0)
return i;
}
@@ -1774,5 +1772,5 @@ static Bool client_perm_maybe_describe(
/* Perhaps it's a general block ? */
for (i = 0; i < vg_cgb_used; i++) {
- if (vg_cgbs[i].kind == CG_NotInUse)
+ if (vg_cgbs[i].start == 0 && vg_cgbs[i].size == 0)
continue;
if (VG_(addr_is_in_block)(a, vg_cgbs[i].start, vg_cgbs[i].size)) {
@@ -1806,4 +1804,5 @@ static Bool client_perm_maybe_describe(
ai->rwoffset = (Int)(a) - (Int)(vg_cgbs[i].start);
ai->lastchange = vg_cgbs[i].where;
+ ai->desc = vg_cgbs[i].desc;
return True;
}
@@ -1855,40 +1854,40 @@ Bool SK_(handle_client_request) ( Thread
case VG_USERREQ__MAKE_NOACCESS: /* make no access */
- i = vg_alloc_client_block();
- /* VG_(printf)("allocated %d %p\n", i, vg_cgbs); */
- vg_cgbs[i].kind = CG_NoAccess;
- vg_cgbs[i].start = arg[1];
- vg_cgbs[i].size = arg[2];
- vg_cgbs[i].where = VG_(get_ExeContext) ( tid );
mc_make_noaccess ( arg[1], arg[2] );
- *ret = i;
+ *ret = -1;
break;
case VG_USERREQ__MAKE_WRITABLE: /* make writable */
- i = vg_alloc_client_block();
- vg_cgbs[i].kind = CG_Writable;
- vg_cgbs[i].start = arg[1];
- vg_cgbs[i].size = arg[2];
- vg_cgbs[i].where = VG_(get_ExeContext) ( tid );
mc_make_writable ( arg[1], arg[2] );
- *ret = i;
+ *ret = -1;
break;
case VG_USERREQ__MAKE_READABLE: /* make readable */
+ mc_make_readable ( arg[1], arg[2] );
+ *ret = -1;
+ break;
+
+ case VG_USERREQ__CREATE_BLOCK: /* describe a block */
+ if (arg[1] != 0 && arg[2] != 0) {
i = vg_alloc_client_block();
- vg_cgbs[i].kind = CG_Readable;
+ /* VG_(printf)("allocated %d %p\n", i, vg_cgbs); */
vg_cgbs[i].start = arg[1];
vg_cgbs[i].size = arg[2];
+ vg_cgbs[i].desc = VG_(strdup)((Char *)arg[3]);
vg_cgbs[i].where = VG_(get_ExeContext) ( tid );
- mc_make_readable ( arg[1], arg[2] );
+
*ret = i;
+ } else
+ *ret = -1;
break;
case VG_USERREQ__DISCARD: /* discard */
if (vg_cgbs == NULL
- || arg[2] >= vg_cgb_used || vg_cgbs[arg[2]].kind == CG_NotInUse)
+ || arg[2] >= vg_cgb_used ||
+ (vg_cgbs[arg[2]].start == 0 && vg_cgbs[arg[2]].size == 0))
return 1;
sk_assert(arg[2] >= 0 && arg[2] < vg_cgb_used);
- vg_cgbs[arg[2]].kind = CG_NotInUse;
+ vg_cgbs[arg[2]].start = vg_cgbs[arg[2]].size = 0;
+ VG_(free)(vg_cgbs[arg[2]].desc);
vg_cgb_discards++;
*ret = 0;
--- valgrind/coregrind/vg_malloc2.c #1.35:1.36
@@ -480,5 +480,5 @@ Superblock* newSuperblock ( Arena* a, Si
}
vg_assert(NULL != sb);
- VALGRIND_DISCARD(VALGRIND_MAKE_WRITABLE(sb, cszB));
+ VALGRIND_MAKE_WRITABLE(sb, cszB);
vg_assert(0 == (Addr)sb % VG_MIN_MALLOC_SZB);
sb->n_payload_bytes = cszB - sizeof(Superblock);
@@ -869,5 +869,5 @@ void mkFreeBlock ( Arena* a, Block* b, S
SizeT pszB = bszB_to_pszB(a, bszB);
vg_assert(b_lno == pszB_to_listNo(pszB));
- VALGRIND_DISCARD(VALGRIND_MAKE_WRITABLE(b, bszB));
+ VALGRIND_MAKE_WRITABLE(b, bszB);
// Set the size fields and indicate not-in-use.
set_bszB_lo(b, mk_free_bszB(bszB));
|
|
From: Jeremy F. <je...@go...> - 2005-03-01 06:20:23
|
CVS commit by fitzhardinge:
Fix sigsuspend properly. This version should keep everyone happy. eff_sig_mask
has been replaced by tmp_sig_mask; unlike eff_sig_mask, tmp_sig_mask has a very
limit scope, and is just used to communicate the temp signal mask between the
sigsuspend syscall and any signal handlers invoked.
M +7 -6 core.h 1.93
M +1 -1 vg_scheduler.c 1.227
M +21 -22 vg_signals.c 1.135
M +12 -6 vg_syscalls.c 1.257
M +1 -1 linux/core_os.c 1.9
M +3 -3 x86/signal.c 1.16
M +2 -2 x86-linux/syscalls.c 1.26
--- valgrind/coregrind/vg_syscalls.c #1.256:1.257
@@ -1821,5 +1821,5 @@ PRE(sys_execve, Special)
;
- VG_(sigprocmask)(VKI_SIG_SETMASK, &tst->eff_sig_mask, NULL);
+ VG_(sigprocmask)(VKI_SIG_SETMASK, &tst->sig_mask, NULL);
}
@@ -5499,5 +5499,4 @@ PRE(sys_pause, MayBlock)
}
-// XXX: x86-specific
PRE(sys_sigsuspend, MayBlock)
{
@@ -5515,7 +5514,7 @@ PRE(sys_sigsuspend, MayBlock)
int, history0, int, history1,
vki_old_sigset_t, mask);
+ convert_sigset_to_rt((const vki_old_sigset_t *)arg3, &tst->tmp_sig_mask);
}
-// XXX: x86-specific
PRE(sys_rt_sigsuspend, MayBlock)
{
@@ -5527,7 +5526,9 @@ PRE(sys_rt_sigsuspend, MayBlock)
*/
PRINT("sys_rt_sigsuspend ( %p, %d )", arg1,arg2 );
- PRE_REG_READ2(int, "rt_sigsuspend", vki_sigset_t *, mask, vki_size_t, size)
- if (arg1 != (Addr)NULL)
+ PRE_REG_READ2(int, "rt_sigsuspend", vki_sigset_t *, mask, vki_size_t, size);
+ if (arg1 != (Addr)NULL) {
SYS_PRE_MEM_READ( "rt_sigsuspend(mask)", arg1, sizeof(vki_sigset_t) );
+ tst->tmp_sig_mask = *(vki_sigset_t *)arg1;
+ }
}
@@ -6099,4 +6100,9 @@ void VG_(client_syscall) ( ThreadId tid
tst->syscallno = syscallno;
+ /* Make sure the tmp signal mask matches the real signal
+ mask; sigsuspend may change this. */
+ vg_assert(tst->sig_mask.sig[0] == tst->tmp_sig_mask.sig[0]);
+ vg_assert(tst->sig_mask.sig[1] == tst->tmp_sig_mask.sig[1]);
+
sys = get_syscall_entry(syscallno);
flags = *(sys->flags_ptr);
@@ -6149,5 +6155,5 @@ void VG_(client_syscall) ( ThreadId tid
PRINT(" --> ...\n");
- mask = tst->eff_sig_mask;
+ mask = tst->sig_mask;
VG_(sanitize_client_sigmask)(tid, &mask);
--- valgrind/coregrind/core.h #1.92:1.93
@@ -632,10 +632,11 @@ struct _ThreadState {
vki_sigset_t sig_mask;
- /* Effective signal mask, eff_sig_mask, is usually identical to
- sig_mask, except when running sigsuspend. sigsuspend sets a
- temporary signal mask while it runs, which is retained while any
- signal handler is run; sig_mask comes into effect once the
- handler has finished. */
- vki_sigset_t eff_sig_mask;
+ /* tmp_sig_mask is usually the same as sig_mask, and is kept in
+ sync whenever sig_mask is changed. The only time they have
+ different values is during the execution of a sigsuspend, where
+ tmp_sig_mask is the temporary mask which sigsuspend installs.
+ It is only consulted to compute the signal mask applied to a
+ signal handler. */
+ vki_sigset_t tmp_sig_mask;
/* A little signal queue for signals we can't get the kernel to
--- valgrind/coregrind/vg_signals.c #1.134:1.135
@@ -673,5 +673,5 @@ void do_setmask ( ThreadId tid,
vg_assert(VG_(is_valid_tid)(tid));
if (oldset) {
- *oldset = VG_(threads)[tid].eff_sig_mask;
+ *oldset = VG_(threads)[tid].sig_mask;
if (VG_(clo_trace_signals))
VG_(message)(Vg_DebugExtraMsg,
@@ -683,5 +683,5 @@ void do_setmask ( ThreadId tid,
VG_(sigdelset)(&VG_(threads)[tid].sig_mask, VKI_SIGKILL);
VG_(sigdelset)(&VG_(threads)[tid].sig_mask, VKI_SIGSTOP);
- VG_(threads)[tid].eff_sig_mask = VG_(threads)[tid].sig_mask;
+ VG_(threads)[tid].tmp_sig_mask = VG_(threads)[tid].sig_mask;
}
}
@@ -820,5 +820,5 @@ void vg_push_signal_frame ( ThreadId tid
vg_scss.scss_per_sig[sigNo].scss_handler,
vg_scss.scss_per_sig[sigNo].scss_flags,
- &vg_scss.scss_per_sig[sigNo].scss_mask,
+ &tst->sig_mask,
vg_scss.scss_per_sig[sigNo].scss_restorer);
}
@@ -1413,5 +1413,5 @@ static void synth_fault_common(ThreadId
/* If they're trying to block the signal, force it to be delivered */
- if (VG_(sigismember)(&VG_(threads)[tid].eff_sig_mask, VKI_SIGSEGV))
+ if (VG_(sigismember)(&VG_(threads)[tid].sig_mask, VKI_SIGSEGV))
VG_(set_default_handler)(VKI_SIGSEGV);
@@ -1503,13 +1503,18 @@ void VG_(deliver_signal) ( ThreadId tid,
}
- /* Handler gets the union of the signal's mask and the thread's
- mask. The original sigmask has already been saved in the
- signal frame, and will be restored on signal return. */
- VG_(sigaddset_from_set)(&tst->eff_sig_mask, &handler->scss_mask);
- VG_(sigaddset_from_set)(&tst->eff_sig_mask, &VG_(threads)[tid].sig_mask);
+ /* At this point:
+ tst->sig_mask is the current signal mask
+ tst->tmp_sig_mask is the same as sig_mask, unless we're in sigsuspend
+ handler->scss_mask is the mask set by the handler
- /* also mask this signal, unless they ask us not to */
- if (!(handler->scss_flags & VKI_SA_NOMASK))
- VG_(sigaddset)(&tst->eff_sig_mask, sigNo);
+ Handler gets a mask of tmp_sig_mask|handler_mask|signo
+ */
+ tst->sig_mask = tst->tmp_sig_mask;
+ if (!(handler->scss_flags & VKI_SA_NOMASK)) {
+ VG_(sigaddset_from_set)(&tst->sig_mask, &handler->scss_mask);
+ VG_(sigaddset)(&tst->sig_mask, sigNo);
+
+ tst->tmp_sig_mask = tst->sig_mask;
+ }
}
@@ -1621,10 +1626,4 @@ void vg_async_signalhandler ( Int sigNo,
sigNo, tid, info->si_code);
- /* Update the thread's effective signal mask. The only syscall
- this should apply to is sigsuspend, which has a temporary signal
- mask set for signals delivered while it is blocked. The signal
- handler will restore this on signal return. */
- tst->eff_sig_mask = uc->uc_sigmask;
-
/* Update thread state properly */
VGA_(interrupted_syscall)(tid, uc,
@@ -1859,5 +1858,5 @@ void vg_sync_signalhandler ( Int sigNo,
ThreadState *tst = VG_(get_ThreadState)(VG_(get_lwp_tid)(VG_(gettid)()));
- if (VG_(sigismember)(&tst->eff_sig_mask, sigNo)) {
+ if (VG_(sigismember)(&tst->sig_mask, sigNo)) {
/* signal is blocked, but they're not allowed to block faults */
VG_(set_default_handler)(sigNo);
@@ -1985,5 +1984,5 @@ void VG_(poll_signals)(ThreadId tid)
/* look for all the signals this thread isn't blocking */
for(i = 0; i < _VKI_NSIG_WORDS; i++)
- pollset.sig[i] = ~tst->eff_sig_mask.sig[i];
+ pollset.sig[i] = ~tst->sig_mask.sig[i];
VG_(sigdelset)(&pollset, VKI_SIGVGCHLD); /* already dealt with */
@@ -2120,5 +2119,5 @@ void VG_(sigstartup_actions) ( void )
vg_assert(VG_(threads)[VG_(master_tid)].status == VgTs_Init);
VG_(threads)[VG_(master_tid)].sig_mask = saved_procmask;
- VG_(threads)[VG_(master_tid)].eff_sig_mask = saved_procmask;
+ VG_(threads)[VG_(master_tid)].tmp_sig_mask = saved_procmask;
/* Calculate SKSS and apply it. This also sets the initial kernel
--- valgrind/coregrind/vg_scheduler.c #1.226:1.227
@@ -509,5 +509,5 @@ void mostly_clear_thread_record ( Thread
VG_(sigemptyset)(&VG_(threads)[tid].sig_mask);
- VG_(sigemptyset)(&VG_(threads)[tid].eff_sig_mask);
+ VG_(sigemptyset)(&VG_(threads)[tid].tmp_sig_mask);
VGA_(os_state_clear)(&VG_(threads)[tid]);
--- valgrind/coregrind/x86-linux/syscalls.c #1.25:1.26
@@ -327,6 +327,6 @@ static Int do_clone(ThreadId ptid,
/* inherit signal mask */
- ctst->sig_mask = ptst->eff_sig_mask;
- ctst->eff_sig_mask = ctst->sig_mask;
+ ctst->sig_mask = ptst->sig_mask;
+ ctst->tmp_sig_mask = ptst->sig_mask;
/* We don't really know where the client stack is, because its
--- valgrind/coregrind/linux/core_os.c #1.8:1.9
@@ -125,5 +125,5 @@ void VGA_(final_tidyup)(ThreadId tid)
the thread's block state*/
VG_(sigprocmask)(VKI_SIG_BLOCK, NULL, &VG_(threads)[tid].sig_mask);
- VG_(threads)[tid].eff_sig_mask = VG_(threads)[tid].sig_mask;
+ VG_(threads)[tid].tmp_sig_mask = VG_(threads)[tid].sig_mask;
/* and restore handlers to default */
--- valgrind/coregrind/x86/signal.c #1.15:1.16
@@ -454,5 +454,5 @@ static Addr build_sigframe(ThreadState *
VG_(memcpy)(&frame->sigContext, &uc.uc_mcontext,
sizeof(struct vki_sigcontext));
- frame->sigContext.oldmask = tst->sig_mask.sig[0];
+ frame->sigContext.oldmask = mask->sig[0];
VG_TRACK( post_mem_write, esp, offsetof(struct sigframe, vg) );
@@ -554,5 +554,5 @@ static Bool restore_vg_sigframe(ThreadSt
tst->sig_mask = frame->mask;
- tst->eff_sig_mask = frame->mask;
+ tst->tmp_sig_mask = frame->mask;
if (VG_(needs).shadow_regs) {
|
|
From: <js...@ac...> - 2005-03-01 04:02:03
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-01 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 207 tests, 11 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-03-01 03:28:24
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-01 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 214 tests, 8 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-01 03:25:12
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-01 03:15:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 213 tests, 6 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-01 02:57:35
|
CVS commit by nethercote: wibble M +4 -4 valgrind-quick-start 1.2 --- devel-home/valgrind/valgrind-quick-start #1.1:1.2 @@ -89,8 +89,8 @@ Memory leak messages look like this: -==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 -==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) -==19182== by 0x8048385: f (a.c:7) -==19182== by 0x80483AB: main (a.c:14) + ==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 + ==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) + ==19182== by 0x8048385: f (a.c:7) + ==19182== by 0x80483AB: main (a.c:14) The stack trace tells you where the leaked memory was allocated. Memcheck |
|
From: Nicholas N. <nj...@cs...> - 2005-03-01 02:56:43
|
CVS commit by nethercote: Added Quick Start doc. A valgrind-quick-start 1.1 M +4 -0 docs.html 1.10 --- devel-home/valgrind/docs.html #1.9:1.10 @@ -5,4 +5,8 @@ ?> +The <a href="valgrind-quick-start">Valgrind Quick Start</a> tells you the +minimum amount of information you need to know to start using detecting +memory errors in your programs. +<p> <a href="http://developer.kde.org/~sewardj/docs-2.2.0/manual.html">Full documentation</a> for version 2.2.0 is supplied, up-to-date as of 31 |
|
From: Jeremy F. <je...@go...> - 2005-03-01 01:17:02
|
CVS commit by fitzhardinge:
Put vg_intercept.o into the right product.
M +1 -2 Makefile.am 1.110
--- valgrind/coregrind/Makefile.am #1.109:1.110
@@ -56,5 +56,4 @@
vg_hashtable.c \
vg_instrument.c \
- vg_intercept.c \
vg_main.c \
vg_malloc2.c \
@@ -127,5 +126,5 @@
$(PERL) $(srcdir)/gen_toolint.pl struct < $(srcdir)/toolfuncs.def >> $@ || rm -f $@
-vg_inject_so_SOURCES =
+vg_inject_so_SOURCES = vg_intercept.c
vg_inject_so_CFLAGS = $(AM_CFLAGS) -fpic
vg_inject_so_LDADD = -ldl
|
|
From: Dirk M. <mu...@kd...> - 2005-03-01 01:10:38
|
CVS commit by mueller:
fix compile (gcc 4.0)
M +1 -1 helpers.S 1.6
--- valgrind/coregrind/x86/helpers.S #1.5:1.6
@@ -64,5 +64,5 @@
ud2
- # We can point our sysinfo stuff here
+ /* We can point our sysinfo stuff here */
.align 16
syscall_start:
|
|
From: Jeremy F. <je...@go...> - 2005-03-01 00:49:49
|
Nicholas Nethercote wrote:
> I'd be happy for VALGRIND_MAKE_* to not create its own blocks, I don't
> think we'd lose much with that. In fact, I vaguely recall that the
> memory address identification code has to do some awkward things to
> deal with those special blocks.
Well, it checks to see if the address is within one. Do you think we
can do without them altogether, or there should be a client call to
create them? I've never used them, but I can see a use, particularly if
you can associate a descriptive string with them which is displayed when
hit.
> As for MALLOCLIKE/FREELIKE, they're good enough for simple custom
> allocators. See memcheck/tests/custom_alloc.c for an example.
custom_alloc.c is a little bit *too* simplistic, since it doesn't
implement free(), or any kind of freelist, or any block recycling. Its
the freelist management which bites you.
> I'm not surprised that they causes problems if you use it with
> malloc(); that's not something I'd considered, because I didn't think
> anyone would build a custom allocator on top of malloc(). There may
> certainly be room for improvement.
I ran into it by accident while trying to come up with a minimal but
slightly more complete replacement for custom_alloc.c. At the very
least the leak checker shouldn't assert over them. Should it simply
ignore AllocCustom chunks if they're embedded within another chunk?
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-01 00:34:00
|
On Mon, 28 Feb 2005, Julian Seward wrote: >>>> Recommendation: make --leak-check=yes the default. >>> >>> What about a lightweight leak-check which is always enabled, but only >>> reports a summary of leaked memory, and a CLO which reports the full >>> details of leaked memory? >> >> I don't see much point. People are mostly using --leak-check=yes, let's >> give them what they're (indirectly) asking for. > > I vote for permanently-enabled summary only, with --leak-check=yes > doing the full thing. Would you be able to turn the leak checker off? I think you should still be able to do that. It takes time, if someone doesn't want to use it, they shouldn't have to. > Advantages: > > * it continually reminds users that leak checking is available > > * it means the leak checker is continually exercised, exposing > any bugs sooner These two are true if you have the full output showing too. > * having the full output enabled by default floods people with too > much info they may not want I disagree. I think it's like increasing num-callers -- there's a reasonable concern with flooding the user with too much info, but really the surveys have clearly shown that's what they want. It's better to have too much info than not enough and have to run your program again. Having said that, you're the boss. N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-01 00:24:52
|
On Mon, 28 Feb 2005, Jeremy Fitzhardinge wrote: >> If anything is to happen to functionality, I'd prefer to prune >> away little-used features to make V easier to maintain. >> > Yeah, I'd agree with that (ie: VALGRIND_MAKE_*). > > The MALLOCLIKE/FREELIKE stuff clearly serves a need for anyone who has > their own allocator (Valgrind, for example), but I'm guessing they > haven't been used much. The mempool changes are presumably useful, > otherwise Robert wouldn't have bothered with them. I'm looking to > condense the normal heap stuff and the mempool stuff into a single > unified mechanism, and make that mechanism actually work in a useful way. > > But I'm not planning on doing anything beyond bug-fixing for now (which > I consider the MAKE_* issue to be). I'd be happy for VALGRIND_MAKE_* to not create its own blocks, I don't think we'd lose much with that. In fact, I vaguely recall that the memory address identification code has to do some awkward things to deal with those special blocks. As for MALLOCLIKE/FREELIKE, they're good enough for simple custom allocators. See memcheck/tests/custom_alloc.c for an example. I'm not surprised that they causes problems if you use it with malloc(); that's not something I'd considered, because I didn't think anyone would build a custom allocator on top of malloc(). There may certainly be room for improvement. N |