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: Jeremy F. <je...@go...> - 2005-03-07 23:39:17
|
CVS commit by fitzhardinge:
Include manpage in package. Also, use the right macro documentation
path. (TODO: specify that path as an argument to autoconf, so that
the %build section can pass %{_docdir} to configure.)
M +4 -2 valgrind.spec.in 1.22
--- valgrind/valgrind.spec.in #1.21:1.22
@@ -27,5 +27,5 @@
%build
-./configure --prefix=/usr
+./configure --prefix=/usr --mandir=%{_mandir}
make
@@ -53,5 +53,7 @@
%doc
-/usr/share/doc/valgrind-@VERSION@/*
+%defattr(-,root,root)
+%{_docdir}/*
+%{_mandir}/*/*
%clean
|
|
From: Jeremy F. <je...@go...> - 2005-03-07 23:07:59
|
CVS commit by fitzhardinge:
Default to using --leak-check=summary.
M +1 -1 memcheck/mac_leakcheck.c 1.23
M +2 -2 memcheck/mac_needs.c 1.37
M +1 -1 tests/vg_regtest.in 1.32
--- valgrind/memcheck/mac_needs.c #1.36:1.37
@@ -50,5 +50,5 @@
Bool MAC_(clo_partial_loads_ok) = True;
Int MAC_(clo_freelist_vol) = 1000000;
-LeakCheckMode MAC_(clo_leak_check) = LC_Off;
+LeakCheckMode MAC_(clo_leak_check) = LC_Summary;
VgRes MAC_(clo_leak_resolution) = Vg_LowRes;
Bool MAC_(clo_show_reachable) = False;
@@ -89,5 +89,5 @@ void MAC_(print_common_usage)(void)
" --partial-loads-ok=no|yes too hard to explain here; see manual [yes]\n"
" --freelist-vol=<number> volume of freed blocks queue [1000000]\n"
-" --leak-check=no|summary|full search for memory leaks at exit? [no]\n"
+" --leak-check=no|summary|full search for memory leaks at exit? [summary]\n"
" --leak-resolution=low|med|high how much bt merging in leak check [low]\n"
" --show-reachable=no|yes show reachable blocks in leak check? [no]\n"
--- valgrind/memcheck/mac_leakcheck.c #1.22:1.23
@@ -661,5 +661,5 @@ void MAC_(do_detect_memory_leaks) (
VG_(message)(Vg_UserMsg, " suppressed: %d bytes in %d blocks.",
MAC_(bytes_suppressed), blocks_suppressed );
- if (mode == LC_Summary)
+ if (mode == LC_Summary && blocks_leaked > 0)
VG_(message)(Vg_UserMsg,
"Use --leak-check=full to see details of leaked memory.");
--- valgrind/tests/vg_regtest.in #1.31:1.32
@@ -281,5 +281,5 @@
# by an "args:" line, though).
my $tool=determine_tool();
- mysystem("VALGRINDLIB=$tests_dir/.in_place $valgrind --command-line-only=yes --tool=$tool $vgopts $prog $args > $name.stdout.out 2> $name.stderr.out");
+ mysystem("VALGRINDLIB=$tests_dir/.in_place $valgrind --command-line-only=yes --memcheck:leak-check=no --addrcheck:leak-check=no --tool=$tool $vgopts $prog $args > $name.stdout.out 2> $name.stderr.out");
if (defined $stdout_filter) {
|
|
From: Jeremy F. <je...@go...> - 2005-03-07 22:06:51
|
CVS commit by fitzhardinge:
BUGFIX: process_cmd_line_options mangles options with the syntax
--TOOLNAME:option=foo. If you use --trace-children=yes, the child
Valgrinds are passed the mangled options and fail as a result.
This patch makes sure that process_cmd_line_options makes a copy of
the option before mangling it.
M +8 -5 vg_main.c 1.263
--- valgrind/coregrind/vg_main.c #1.262:1.263
@@ -1626,5 +1626,5 @@ static void process_cmd_line_options( UI
if (0)
VG_(printf)("tool-specific arg: %s\n", arg);
- arg += toolname_len + 1;
+ arg = strdup(arg + toolname_len + 1);
arg[0] = '-';
arg[1] = '-';
@@ -1638,12 +1638,12 @@ static void process_cmd_line_options( UI
/* Ignore these options - they've already been handled */
if (VG_CLO_STREQN(7, arg, "--tool="))
- continue;
+ goto skip_arg;
if (VG_CLO_STREQN(7, arg, "--exec="))
- continue;
+ goto skip_arg;
if (VG_CLO_STREQN(20, arg, "--command-line-only="))
- continue;
+ goto skip_arg;
if ( VG_CLO_STREQ(arg, "--"))
- continue;
+ goto skip_arg;
else if (VG_CLO_STREQ(arg, "-v") ||
@@ -1756,4 +1756,7 @@ static void process_cmd_line_options( UI
VG_(bad_option)(arg);
}
+ skip_arg:
+ if (arg != vg_argv[i])
+ free(arg);
}
|
|
From: Jeremy F. <je...@go...> - 2005-03-07 16:30:37
|
Josef Weidendorfer wrote:
>On Monday 07 March 2005 02:28, Jeremy Fitzhardinge wrote:
>
>
>>This patch makes everything fail with
>>
>>Tool error:
>> The tool you have selected is missing the function `track_new_segment',
>> which is required.
>>
>>
>
>Oopps. I had the hooks always above the ":track" line in toolfuncs.def, but
>moved it more to the bottom as for the first part, function invocations
>seemed to depend on some VG_(needs). What is the difference here?
>
If you use SK_(X) directly, then it will simply try to call the tool
func 'X', and fail with this message if the tool didn't define it. If
you use VG_TRACK(X), it wil only call it if the tool defined it.
J
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-07 15:11:55
|
On Mon, 7 Mar 2005, Josef Weidendorfer wrote: > Regarding the new IR, I don't think there will be too much changes. > Calltree, like Cachegrind, never used UCode directly. Er, yes it does! See SK_(instrument)() :) N |
|
From: Dirk M. <dm...@gm...> - 2005-03-07 14:18:35
|
On Saturday 05 March 2005 02:23, Jeremy Fitzhardinge wrote: > If the Vex-mainline merge commit happens before the CVS migration, we'll > end up with broken history. I'm not sure if you're following KDE development, but KDE is switching to SVN pretty soon (within the next few weeks). Dirk |
|
From: Josef W. <Jos...@gm...> - 2005-03-07 12:45:41
|
On Monday 07 March 2005 01:23, Julian Seward wrote: > Josef > > Really we are very close to a 2.4 release, and I don't want to put > in new code at this point. We are doing docs-only changes now, and > I want to ship 2.4 asap. > > New functionality can go into the 3.0 dev branch, which in any case > will cause other changes for Calltree since there is a new IR (UCode > is dead). Hi, no problem on my side. I simply was not sure if a few small hooks for tools would still be able to make it in. For 3.x, it would be good if the debug reader could get a nice request interface inside of the tool API, e.g. iterators over functions, source lines, but also static data structures and type info. Regarding the new IR, I don't think there will be too much changes. Calltree, like Cachegrind, never used UCode directly. On Monday 07 March 2005 02:28, Jeremy Fitzhardinge wrote: > This patch makes everything fail with > > Tool error: > The tool you have selected is missing the function `track_new_segment', > which is required. Oopps. I had the hooks always above the ":track" line in toolfuncs.def, but moved it more to the bottom as for the first part, function invocations seemed to depend on some VG_(needs). What is the difference here? Josef |
|
From: <js...@ac...> - 2005-03-07 04:01:18
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-07 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse 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 ---------------------------------------- == 198 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) corecheck/tests/fdleak_fcntl (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-03-07 03:28:29
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-07 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int sh: line 1: 30944 Segmentation fault VALGRINDLIB=/tmp/valgrind.5946/valgrind/.in_place /tmp/valgrind.5946/valgrind/./coregrind/valgrind --command-line-only=yes --tool=none ./int >int.stdout.out 2>int.stderr.out 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 ---------------------------------------- == 204 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-07 03:22:16
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-07 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fpu_lazy_eflags: valgrind ./fpu_lazy_eflags insn_basic: valgrind ./insn_basic insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse 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 ---------------------------------------- == 203 tests, 0 stderr failures, 0 stdout failures ================= |
|
From: Tom H. <th...@cy...> - 2005-03-07 03:16:20
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-07 03:10:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse 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 ---------------------------------------- == 202 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-07 03:15:28
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-07 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse 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 ---------------------------------------- == 202 tests, 5 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-tree (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-07 03:11:35
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-07 03:05:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 202 tests, 17 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) addrcheck/tests/leak-0 (stderr) addrcheck/tests/leak-cycle (stderr) addrcheck/tests/leak-regroot (stderr) addrcheck/tests/leak-tree (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-03-07 02:12:38
|
Julian Seward wrote:
>Josef
>
>Really we are very close to a 2.4 release, and I don't want to put
>in new code at this point. We are doing docs-only changes now, and
>I want to ship 2.4 asap.
>
>New functionality can go into the 3.0 dev branch, which in any case
>will cause other changes for Calltree since there is a new IR (UCode
>is dead).
>
I expect there'll be a 2.4.1 before 3.0 anyway. 2.4 is much more likely
to be in the next distro cycle.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-07 02:11:51
|
Josef Weidendorfer wrote:
>Hi,
>
>On Saturday 05 March 2005 01:56, Julian Seward wrote:
>
>
>>It seems to me we should be very close to a 2.4.0 freeze.
>>
>>
>
>may I ask for a small set of additional tool API functions? I'm currently
>working on data structure related profiling info, and for that to be
>acceptable, I need to maintain a mapping table from address to objects. For
>static objects, I have to hook into symbol loading, and that is what the tool
>API addition is for.
>
>
This patch makes everything fail with
Tool error:
The tool you have selected is missing the function `track_new_segment',
which is required.
Nulgrind: the `impossible' happened:
Missing tool function
J
|
|
From: Julian S. <js...@ac...> - 2005-03-07 00:24:00
|
Josef Really we are very close to a 2.4 release, and I don't want to put in new code at this point. We are doing docs-only changes now, and I want to ship 2.4 asap. New functionality can go into the 3.0 dev branch, which in any case will cause other changes for Calltree since there is a new IR (UCode is dead). J On Sunday 06 March 2005 19:27, Josef Weidendorfer wrote: > Hi, > > On Saturday 05 March 2005 01:56, Julian Seward wrote: > > It seems to me we should be very close to a 2.4.0 freeze. > > may I ask for a small set of additional tool API functions? I'm currently > working on data structure related profiling info, and for that to be > acceptable, I need to maintain a mapping table from address to objects. For > static objects, I have to hook into symbol loading, and that is what the > tool API addition is for. > > Josef |