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: Donna R. <do...@te...> - 2005-03-23 18:34:16
|
On Wednesday 23 March 2005 18:17, Jeremy Fitzhardinge wrote: > When I've been training people to use Valgrind, I generally recommend > they use addrcheck first, and then move to memcheck once addrcheck is > quiet. This is for one big reason: addrcheck is much easier to understand. Totally agree. > If addrcheck generates a message it is almost certainly a bug, and [large snip] My 10 cents worth: rather than maintaining two such similar tools, give memcheck a flag "--naive" or some such, which makes it behave a la addrcheck, ==> everyone happy. de |
|
From: Oswald B. <os...@kd...> - 2005-03-23 18:32:58
|
On Wed, Mar 23, 2005 at 10:17:27AM -0800, Jeremy Fitzhardinge wrote: > Couldn't that be shared? > taking this to the extreme, possibly close-to-impossible: would it be possible to create a(n efficient) tool stacking architecture? this would sort of resolve the addrcheck vs. memcheck question (by making memcheck addrcheck + initcheck). this might also be interesting in conjunction with "unrelated" tools, as sometimes there are correlations between bugs of different classes. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Robert W. <rj...@du...> - 2005-03-23 18:30:26
|
Could addrcheck and memcheck be rolled into one? In other words, a "quiet" version of memcheck that produces only what reports addrcheck would produce? Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Jeremy F. <je...@go...> - 2005-03-23 18:17:32
|
Julian Seward wrote:
>* The real killer is that I bet practically nobody uses Addrcheck.
> Memcheck tells us everything Addrcheck does, and much more
> besides.
>
>* The performance motivations for Addrcheck turned out not to be
> as convincing as first hoped:
>
> - it isn't a whole lot faster than Memcheck. Memcheck's V bit
> stuff is all done in-line, which is relatively quick. Both
> of them have to call out to helpers to deal with loads/stores,
> and that's the slow bit.
>
> - we're learning that with a bit of care, it's possible to
> reduce -- possibly drastically reduce -- Memcheck's memory
> consumption without changing its behaviour.
>
>
When I've been training people to use Valgrind, I generally recommend
they use addrcheck first, and then move to memcheck once addrcheck is
quiet. This is for one big reason: addrcheck is much easier to understand.
If addrcheck generates a message it is almost certainly a bug, and it
explains everything which needs fixing right there. There's hardly any
need for deep analysis, and it almost never generates false positives.
I can say with confidence that every message represents a core-dump
avoided by dumb luck, and it needs fixing. I only recommend memcheck
once addrcheck is clean, or if the bug seems more elusive. By then
they're used to working with Valgrind, parsing the messages, etc, and
are in a better state to deal with memcheck's subtleties.
Also, our target hardware is pretty slow and memory constrained, which
magnifies addrcheck's performance advantage.
>To put this in perspective, currently the shadow memory machinery
>in Memcheck only works on 32-bit little endian platforms. I've
>been musing on how to fix it to be good for any combination of
>32/64-bitness and little/bigendian-ness. That's additional
>complication which I'd prefer not to have to do for both
>Memcheck and Addrcheck.
>
Once you've solved it for memcheck, surely the same solution would apply
to addrcheck? Or is it a question of complex implementation? Couldn't
that be shared? I would have thought Vex would make it easier to share
the implementation, and compose various pieces of instrumentation
generation from smaller parts.
J
|
|
From: Julian S. <js...@ac...> - 2005-03-23 14:07:55
|
This is a request for comments.
I'm thinking about getting rid of Addrcheck. Originally I made
Addrcheck as an experiment to see how much faster/smaller Memcheck
would be without all the V-bit stuff, and parked it in the repo.
=46rom the point of view of "here's an interesting hack" that's
fine. But that was then and this is now. Now I'm more interested
in looking at things the point of view of "how do we minimise our=20
long-term maintenance burden". It seems to me Addrcheck isn't worth
retaining:
* Addrcheck itself needs maintenance.
* There's a load of stuff shared between Addrcheck and Memcheck.
Although this factoring was done admirably well, it's still
extra complexity to have to deal with.
* The real killer is that I bet practically nobody uses Addrcheck.
Memcheck tells us everything Addrcheck does, and much more
besides.
* The performance motivations for Addrcheck turned out not to be
as convincing as first hoped:
- it isn't a whole lot faster than Memcheck. Memcheck's V bit
stuff is all done in-line, which is relatively quick. Both
of them have to call out to helpers to deal with loads/stores,
and that's the slow bit.
- we're learning that with a bit of care, it's possible to
reduce -- possibly drastically reduce -- Memcheck's memory
consumption without changing its behaviour.
To put this in perspective, currently the shadow memory machinery
in Memcheck only works on 32-bit little endian platforms. I've=20
been musing on how to fix it to be good for any combination of=20
32/64-bitness and little/bigendian-ness. That's additional
complication which I'd prefer not to have to do for both=20
Memcheck and Addrcheck.
Comments?
J
|
|
From: Julian S. <js...@ac...> - 2005-03-23 10:54:31
|
(The first version of this message disappeared into a black hole. This is a re-send. Note, for "tomorrow" now read "today") -------- Unless anyone violently objects, tomorrow I will package up 2.4.0, do some final tests, and assuming nothing nasty comes to light, release the thing. It contains Jeremy's anti-deadlock fixes, which work OK on both SuSE 9.1 (PosixThreads), SuSE 9.2 (NPTL) and RedHat 7.3. I did contemplate doing a rc5, but time is moving on, and so I'm going direct to 2.4.0. Yell *now* if any of this is a problem. J |
|
From: Julian S. <js...@ac...> - 2005-03-23 04:15:47
|
Unless anyone violently objects, tomorrow I will package up 2.4.0, do some final tests, and assuming nothing nasty comes to light, release the thing. It contains Jeremy's anti-deadlock fixes, which work OK on both SuSE 9.1 (PosixThreads), SuSE 9.2 (NPTL) and RedHat 7.3. I did contemplate doing a rc5, but time is moving on, and so I'm going direct to 2.4.0. Yell *now* if any of this is a problem. J |
|
From: <js...@ac...> - 2005-03-23 04:04:47
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-23 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_mmx: valgrind ./insn_mmx insn_mmxext: (skipping, prereq failed: ../../../tests/cputest x86-mmxext) insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int 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 ---------------------------------------- == 201 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: Jeremy F. <je...@go...> - 2005-03-23 03:30:32
|
CVS commit by fitzhardinge:
Handle a couple kinds of executable mutation: a read-only bss, and a
zero-length segment.
M +9 -7 ume.c 1.42
--- valgrind/coregrind/ume.c #1.41:1.42
@@ -244,4 +244,5 @@ ESZ(Addr) mapelf(struct elfinfo *e, ESZ(
brkaddr = addr+memsz;
+ if (ROUNDUP(bss, align)-ROUNDDN(addr, align) > 0) {
res = mmap((char *)ROUNDDN(addr, align),
ROUNDUP(bss, align)-ROUNDDN(addr, align),
@@ -249,4 +250,5 @@ ESZ(Addr) mapelf(struct elfinfo *e, ESZ(
check_mmap(res, (char*)ROUNDDN(addr,align),
ROUNDUP(bss, align)-ROUNDDN(addr, align));
+ }
/* if memsz > filesz, then we need to fill the remainder with zeroed pages */
@@ -262,5 +264,5 @@ ESZ(Addr) mapelf(struct elfinfo *e, ESZ(
bytes = bss & (VKI_PAGE_SIZE - 1);
- if (bytes > 0) {
+ if ((prot & PROT_WRITE) && (bytes > 0)) {
bytes = VKI_PAGE_SIZE - bytes;
memset((char *)bss, 0, bytes);
|
|
From: Jeremy F. <je...@go...> - 2005-03-23 03:29:33
|
CVS commit by fitzhardinge:
Avoid divide by 0 if there are no ccalls.
M +5 -0 vg_from_ucode.c 1.93
--- valgrind/coregrind/vg_from_ucode.c #1.92:1.93
@@ -155,4 +155,9 @@ static Histogram histogram[100];
void VG_(print_ccall_stats)(void)
{
+ if (ccalls == 0) {
+ VG_(message)(Vg_DebugMsg, " No ccalls");
+ return;
+ }
+
VG_(message)(Vg_DebugMsg,
" ccalls: %u C calls, %u%% saves+restores avoided"
|
|
From: Tom H. <to...@co...> - 2005-03-23 03:28:38
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-23 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_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 sh: line 1: 9355 Segmentation fault VALGRINDLIB=/tmp/valgrind.16675/valgrind/.in_place /tmp/valgrind.16675/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --addrcheck:leak-check=no --tool=none ./int >int.stdout.out 2>int.stderr.out 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 ---------------------------------------- == 207 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-23 03:22:36
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-23 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 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 ---------------------------------------- == 206 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-23 03:16:33
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-23 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_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 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 ---------------------------------------- == 205 tests, 3 stderr failures, 0 stdout failures ================= memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-23 03:15:27
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-23 03:00:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int 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 ---------------------------------------- == 205 tests, 6 stderr failures, 0 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (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-23 03:11:59
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-23 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow == 205 tests, 17 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/distinguished-writes (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (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) make: *** [regtest] Error 1 |