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: <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 |