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
(22) |
2
(19) |
3
(8) |
4
(34) |
5
(14) |
6
(14) |
|
7
(12) |
8
(15) |
9
(15) |
10
(10) |
11
(10) |
12
(28) |
13
(11) |
|
14
(22) |
15
(29) |
16
(20) |
17
(15) |
18
(39) |
19
(11) |
20
(12) |
|
21
(8) |
22
(9) |
23
(8) |
24
(10) |
25
(9) |
26
(7) |
27
(7) |
|
28
(6) |
29
(6) |
30
(11) |
|
|
|
|
|
From: Johannes S. <Joh...@gm...> - 2004-11-20 21:06:58
|
Hi, On Sat, 20 Nov 2004, Nicholas Nethercote wrote: > On Sat, 20 Nov 2004, Johannes Schindelin wrote: > > >> I never understood why we care about statically linked executables. > > > > Valgrind started as just a good memory leak checker. As it evolved, it got > > possible to make use of it to do reverse engineering - a sort of "call > > tree for assembler". > > Sorry, I don't see how this relates to statically linked binaries? Sorry, I was a bit terse: Suppose you have a statically linked binary. You don't have the source code, and you will never get it. This program does a lot of useful things, but you are interested in exactly one function. To find out where the code for this function is, in order to analyse that assembly code, you can "follow the data", i.e. you can write a program which knows at which point in memory the input is stored, marks this as interesting data, and then executes the program, marking all memory locations which contain derived data, and all conditional jumps depending on the values of marked data as interesting. In this manner, you can get a good idea where to look closely at the assembly code. Unfortunately, I did not yet succeed to do this with valgrind, but I used bochs for this some years ago. I plan to do this sometime next year with valgrind, because it is much easier (as compared to bochs) to mark the initial interesting data, and it is way faster. The only problem there would be tracking of interesting data in the registers. And I didn't mean to say "just another memory leak checker"; I rather meant that when valgrind v1 was current, I used valgrind to prove to a software vendor that indeed, his program was faulty, and no, my data was not too large for the application. I even could point to a certain code range where memory was eaten away, when it should have been freed at each iteration of a for loop. So I should have said "I got addicted to valgrind when I used it just as a memory leak checker, when LD_PRELOAD methods didn't work because the malloc syscall was called directly". Keep up the good work, Dscho |
|
From: Julian S. <js...@ac...> - 2004-11-20 16:25:21
|
On Saturday 20 November 2004 16:03, Nicholas Nethercote wrote: > On Sat, 20 Nov 2004, Johannes Schindelin wrote: > >> I never understood why we care about statically linked executables. > >> My view is they are a special-case anomaly which it is not worth > >> supporting. No developer doing day-to-day hacking is going to > >> continually be building statically linked executables (are they?) IMO > >> just detecting them and stopping with a warning is good enough. > > > > Valgrind started as just a good memory leak checker. As it evolved, it > > got possible to make use of it to do reverse engineering - a sort of > > "call tree for assembler". > > Sorry, I don't see how this relates to statically linked binaries? Me neither. Besides, if I merely wanted a leak checker I would never have jumped through 10000 hoops to build a simulated CPU. It really started out as a good uninitialised-value detector. J |
|
From: Nicholas N. <nj...@ca...> - 2004-11-20 16:03:45
|
On Sat, 20 Nov 2004, Johannes Schindelin wrote: >> I never understood why we care about statically linked executables. >> My view is they are a special-case anomaly which it is not worth supporting. >> No developer doing day-to-day hacking is going to continually be building >> statically linked executables (are they?) IMO just detecting them and >> stopping with a warning is good enough. > > Valgrind started as just a good memory leak checker. As it evolved, it got > possible to make use of it to do reverse engineering - a sort of "call > tree for assembler". Sorry, I don't see how this relates to statically linked binaries? N |
|
From: Johannes S. <Joh...@gm...> - 2004-11-20 15:49:34
|
Hi, On Sat, 20 Nov 2004, Julian Seward wrote: > I never understood why we care about statically linked executables. > My view is they are a special-case anomaly which it is not worth supporting. > No developer doing day-to-day hacking is going to continually be building > statically linked executables (are they?) IMO just detecting them and > stopping with a warning is good enough. Valgrind started as just a good memory leak checker. As it evolved, it got possible to make use of it to do reverse engineering - a sort of "call tree for assembler". Ciao, Dscho |
|
From: Julian S. <js...@ac...> - 2004-11-20 12:08:44
|
> Having our own libc is definitely not a good idea, but we haven't gone > to much effort to replace it yet. glibc makes it hard to intercept brk > directly, but it is possible to replace malloc/calloc/realloc/etc and be > reasonably sure of avoiding the use of brk (particularly if you get the > kernel to enforce it). > > Having our own libc going to be a portability liability. I have to disagree. Having our own mini-glibc decouples us from the vagaries of what's supplied as libc on, eg, *BSD, Solaris, AIX, etc. If we were going to reproduce a large fraction of glibc then it would be a liability, but we only use a small amount. I am in favour of a "system abstraction layer" to support V's internal activities, such as Mozilla's NPR (?) and OOo's SAL. Clearly it would be smaller and simpler than either of those, but the principle is the same. > > 3. P can clobber V's memory. > > > > Partial success. P can't clobber V; but I'm not sure how much of a > > problem this was in the first place. (Are there any cases > > where Memcheck wouldn't report the clobbering first?) Also, x86 > > segment selectors aren't portable, and no convincing alternative is > > known for other architectures. > > memcheck and addrcheck will report on out of bounds writes, but other > tools won't. In addition, if you get an out of bounds error which > doesn't crash the process, it immediately means that all other program > and valgrind output is unreliable, so you need to be very strict about > fixing the first problem before considering the rest. I think this > makes the Valgrind output unreliable. I never got the impression from user feedback that the P-clobbers-V problem was significant. What's more, telling people to fix errors in the order is necessary even at present: even if P does not trash V, errors often form cascades, and it is the first one that needs to be fixed first. > Well, hm. If Valgrind is sharing ld.so with the client, then they're > not really separate programs at all. If the client screws up the > dynamic linker, Valgrind could get hit and crash without being able to > report on it at all. The underlying issue here is that mc/ac access control is too crude. For a while I have been thinking about 2 A bits per byte, one for read/exec access and one for write. Then executable areas could be marked as readonly and the above cannot happen. It would also finally give us Robert's memory watchpoints for free. > > 5. Intercepting library calls is difficult and fragile. > > > > ??? It still seems difficult, but I don't understand that stuff at > > all. Can someone elaborate? > > The machinery in there now is pretty simple. You list a set of > addresses of functions you want to intercept, and when the codegen is > told to fetch from those addresses, it actually fetches from the > intercepting function instead. The addresses can be specified either > literally or symbolically; symbol names can be qualified by a particular > library name, or be unqualified. glibc makes complex by being complex > itself, but the core machinery is pretty simple. Yes, I agree -- it's not that complex. > > 6. Statically linked programs are not supported. > > > > Partial success. We can run statically linked binaries. However, we > > can't intercept malloc() et al, which hobbles tools to various > > degrees (eg. Cachegrind not at all, Memcheck somewhat, Addrcheck > > quite a lot, Massif totally). > > We can intercept malloc/free/etc if the program hasn't been stripped. > Its just that with dynamic linking, the programs are never (can't be) > completely stripped. I never understood why we care about statically linked executables. My view is they are a special-case anomaly which it is not worth supporting. No developer doing day-to-day hacking is going to continually be building statically linked executables (are they?) IMO just detecting them and stopping with a warning is good enough. > > - Also, the inflexibility of the memory layout has caused many problems: > > - difficulties for non-standard (ie. 3G:1G) kernels > > - can't run with a virtual memory ulimit (bad esp. for embedded > > developers) > > Can you explain? What do you mean by "embedded developers"? The I guess, developers operating in scenarios with small amounts of virtual memory? > > V has dropped from #6 to #72 highest-rated project at Freshmeat.net over > > the last year or so; I think the reason for this is that V's "it just > > works" characteristic has been diminished, due to the robustness and > > inflexibility problems. > > Um, do you have anything to support that? I think the ranking is > dropping because V is not new anymore, and people are taking it for > granted. I tend to agree. Not convinced that V is particularly much more buggy than before. > > - V and P mappings are totally intermingled. We just let the kernel > > mmap things wherever it wants, without trying to enforce any layout > > ourselves. (This precludes big-bang shadow allocation, and thus > > precludes fixed-offset shadow memory addressing being used in the > > future. This does not worry me.) This makes startup much easier, > > since we don't have to be so careful about where things go. > > ... > I guess my OS/kernel background is really making me dislike this idea. Uh ... you need to say *why* you dislike the idea. Why? > > - Self-hosting might be possible now that Valgrind (ie. stage1) is a > > normal executable again, rather than a .so as it was originally? Not > > sure. > > Don't see why. That's not the hard part of self-hosting. The tricky > part is making the system emulation match what Valgrind itself uses > (which in turn needs improvements to the VCPU's exception model). The new VCPU (VEX) provides precise (memory) exceptions if you need them. > The increased layout flexibility is the only obvious win to me, and I > think it costs quite a bit. And now that I have a 64-bit machine, I can > easily say that this is all a lot of engineering effort to keep obsolete > systems happy ;-). :-) the obsolete systems are going to be around for a *long* time yet :-) and will probably always be the majority. J |
|
From: Nicholas N. <nj...@ca...> - 2004-11-20 11:33:38
|
CVS commit by nethercote:
update
M +4 -5 related.html 1.22
--- devel-home/valgrind/related.html #1.21:1.22
@@ -26,9 +26,8 @@
can profile shared libraries.
<p>
-<li>Nick Nethercote has several experimental tools: a memory access tracer, a
- heap profiler, a pointer misuse-checker, and a signal-handler checker. He
- also has an experimental Valgrind distribution that has an interactive
- command line. They are all available
- <a href="http://www.cl.cam.ac.uk/~njn25/valgrind.html">here</a>.
+<li>Nick Nethercote has several experimental tools: a memory access tracer,
+ a pointer misuse-checker, and a signal-handler checker.
+ They are all available <a
+ href="http://www.cl.cam.ac.uk/~njn25/software.html">here</a>.
<p>
<li>Robert Walsh has a page of useful
|
|
From: <js...@ac...> - 2004-11-20 03:57:39
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-11-20 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 ---------------------------------------- == 186 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-11-20 03:26:18
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2004-11-20 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 191 tests, 14 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/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-20 03:20:14
|
Nightly build on audi ( Red Hat 9 ) started at 2004-11-20 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-20 03:11:29
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-11-20 03:10:01 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow Making check in x86-linux make[2]: Entering directory `/tmp/valgrind.6489/valgrind/coregrind/x86-linux' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/valgrind.6489/valgrind/coregrind/x86-linux' Making check in demangle make[2]: Entering directory `/tmp/valgrind.6489/valgrind/coregrind/demangle' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/valgrind.6489/valgrind/coregrind/demangle' Making check in . make[2]: Entering directory `/tmp/valgrind.6489/valgrind/coregrind' source='vg_from_ucode.c' object='stage2-vg_from_ucode.o' libtool=no \ depfile='.deps/stage2-vg_from_ucode.Po' tmpdepfile='.deps/stage2-vg_from_ucode.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I../coregrind -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I../include -I../include/x86 -I../include/linux -I../include/x86-linux -DVG_LIBDIR="\"/tmp/valgrind.6489/valgrind/Inst/lib/valgrind"\" -I./demangle -DKICKSTART_BASE=0xb0000000 -DVG_PLATFORM="\"x86-linux"\" -Winline -Wall -Wshadow -O -g -fomit-frame-pointer -mpreferred-stack-boundary=2 -DELFSZ=32 -c -o stage2-vg_from_ucode.o `test -f 'vg_from_ucode.c' || echo './'`vg_from_ucode.c cc1: No space left on device: error writing to /tmp/ccUwAE3P.s make[2]: *** [stage2-vg_from_ucode.o] Error 1 make[2]: Leaving directory `/tmp/valgrind.6489/valgrind/coregrind' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.6489/valgrind/coregrind' make: *** [check-recursive] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-20 03:08:46
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-11-20 03:05:02 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 ---------------------------------------- == 191 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-20 03:04:19
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-11-20 03:00:03 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 ---------------------------------------- == 191 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |