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
(6) |
2
(3) |
3
|
4
(3) |
5
(10) |
6
(4) |
7
(5) |
|
8
(1) |
9
(3) |
10
(11) |
11
(18) |
12
(13) |
13
(4) |
14
(11) |
|
15
(12) |
16
(6) |
17
(1) |
18
(13) |
19
(14) |
20
(12) |
21
(3) |
|
22
(17) |
23
(18) |
24
(17) |
25
(24) |
26
(15) |
27
(7) |
28
(23) |
|
29
(31) |
|
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-02-18 18:23:38
|
On Wed, 2004-02-18 at 09:45, Doug Rabson wrote: > Oh - I assumed this didn't work for static programs. Last time I ran a > static program, V started complaining about bitmap nits inside FreeBSD's > malloc. Looks like a bug in the FreeBSD version :-( Well, when I say "libc's version", I mean the one in libc.so - it doesn't look for a malloc in the main executable. But all the machinery to do it is there, and it should be easy enough to add. BTW, I'm still not really happy with how the whole symbol interception stuff works in CVS, but I'm not quite sure what the best fix is... J |
|
From: Doug R. <df...@nl...> - 2004-02-18 17:50:40
|
On Wed, 2004-02-18 at 17:41, Jeremy Fitzhardinge wrote:
> On Wed, 2004-02-18 at 08:15, Josef Weidendorfer wrote:
> > With debug info, you can catch malloc() calls at instrumentation of first
> > basic block: make the instrumentation to be a JMP to a replacement function.
> > This should also work in the shared library case.
> >
> > Isn't this already done ("kludge") in some cases?
>
> It already does this for libc's malloc. BTW, you don't need full debug
> info, just a symbol table.
Oh - I assumed this didn't work for static programs. Last time I ran a
static program, V started complaining about bitmap nits inside FreeBSD's
malloc. Looks like a bug in the FreeBSD version :-(
|
|
From: Jeremy F. <je...@go...> - 2004-02-18 17:46:33
|
On Wed, 2004-02-18 at 08:15, Josef Weidendorfer wrote:
> With debug info, you can catch malloc() calls at instrumentation of first
> basic block: make the instrumentation to be a JMP to a replacement function.
> This should also work in the shared library case.
>
> Isn't this already done ("kludge") in some cases?
It already does this for libc's malloc. BTW, you don't need full debug
info, just a symbol table.
J
|
|
From: Jeremy F. <je...@go...> - 2004-02-18 17:44:59
|
On Wed, 2004-02-18 at 03:37, Doug Rabson wrote: > On Wed, 2004-02-18 at 11:07, Nicholas Nethercote wrote: > > > ------------- > > > "Pthreads support is improving, but there are still significant > > > limitations in that department. See the section above on Pthreads. Note > > > that your program must be dynamically linked against libpthread.so, so > > > that Valgrind can substitute its own implementation at program startup > > > time. If you're statically linked against it, things will fail badly." > > > ------------- > > > > Interesting question for FV: if a program is statically linked, and it > > uses pthreads, can Valgrind handle it? V's libpthread.so won't replace > > libc's, will it? > > None of valgrind's overrides (malloc, free etc.) will work for static > programs. That's true, but it would be easy to fix. For the most part, V doesn't rely on ld.so for intercepting symbols anymore, it uses code redirection. At the moment it specifically looks for malloc/free/etc in libc.so, but it would be easy to make it look them in the main executable (assuming that functions which happen to be named malloc/free/etc are actually functionally equivalent to the libc versions). libpthread is different, since we do actually need to replace it outright. Once we start doing a proper clone() emulation, this won't be an issue. J |
|
From: Josef W. <Jos...@gm...> - 2004-02-18 16:20:14
|
On Wednesday 18 February 2004 16:10, Doug Rabson wrote:
> On Wed, 2004-02-18 at 14:34, Nicholas Nethercote wrote:
> > That's going to degrade the effectiveness of the various tools by
> > different amounts. For example, Memcheck/Addrcheck will not give errors
> > for heap-block overruns, because it will be tracking addressability at
> > the lower mmap/brk level. And Massif (heap profiler) will be useless.
> > It would be good to give some kind of warning about this.
>
> I wonder if it might be possible to catch thing at the instrumentation
> state, e.g. "hey! thats a call to malloc - substitute this pointer
> instead".
This is only possible if debug info is available. Otherwise there is no
way to detect that a function at a given address is "malloc()" (Or does it
make sense to get some MD5 checksum for a static version of malloc on a given
system at compile time of valgrind and search at runtime for this checksum? I
suppose that relocations can make this impossible).
With debug info, you can catch malloc() calls at instrumentation of first
basic block: make the instrumentation to be a JMP to a replacement function.
This should also work in the shared library case.
Isn't this already done ("kludge") in some cases?
Josef
>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Doug R. <df...@nl...> - 2004-02-18 15:16:00
|
On Wed, 2004-02-18 at 14:34, Nicholas Nethercote wrote: > On Wed, 18 Feb 2004, Doug Rabson wrote: > > > It runs fine, > > Even pthreaded programs? How? Probably not pthreaded programs :-( > > > you just don't get the extra malloc/free instrumentation > > etc. > > That's going to degrade the effectiveness of the various tools by > different amounts. For example, Memcheck/Addrcheck will not give errors > for heap-block overruns, because it will be tracking addressability at the > lower mmap/brk level. And Massif (heap profiler) will be useless. It > would be good to give some kind of warning about this. I wonder if it might be possible to catch thing at the instrumentation state, e.g. "hey! thats a call to malloc - substitute this pointer instead". |
|
From: Nicholas N. <nj...@ca...> - 2004-02-18 14:39:25
|
On Wed, 18 Feb 2004, Doug Rabson wrote: > It runs fine, Even pthreaded programs? How? > you just don't get the extra malloc/free instrumentation > etc. That's going to degrade the effectiveness of the various tools by different amounts. For example, Memcheck/Addrcheck will not give errors for heap-block overruns, because it will be tracking addressability at the lower mmap/brk level. And Massif (heap profiler) will be useless. It would be good to give some kind of warning about this. N |
|
From: Doug R. <df...@nl...> - 2004-02-18 13:42:42
|
On Wed, 2004-02-18 at 11:40, Nicholas Nethercote wrote: > On Wed, 18 Feb 2004, Doug Rabson wrote: > > > > Interesting question for FV: if a program is statically linked, and it > > > uses pthreads, can Valgrind handle it? V's libpthread.so won't replace > > > libc's, will it? > > > > None of valgrind's overrides (malloc, free etc.) will work for static > > programs. > > Hmm, yeah. Wasn't the ability to (usefully) run static binaries meant to > be one of the advantages of FV? It runs fine, you just don't get the extra malloc/free instrumentation etc. |
|
From: Nicholas N. <nj...@ca...> - 2004-02-18 11:45:42
|
On Wed, 18 Feb 2004, Doug Rabson wrote: > > Interesting question for FV: if a program is statically linked, and it > > uses pthreads, can Valgrind handle it? V's libpthread.so won't replace > > libc's, will it? > > None of valgrind's overrides (malloc, free etc.) will work for static > programs. Hmm, yeah. Wasn't the ability to (usefully) run static binaries meant to be one of the advantages of FV? N |
|
From: Doug R. <df...@nl...> - 2004-02-18 11:42:44
|
On Wed, 2004-02-18 at 11:07, Nicholas Nethercote wrote: > > ------------- > > "Pthreads support is improving, but there are still significant > > limitations in that department. See the section above on Pthreads. Note > > that your program must be dynamically linked against libpthread.so, so > > that Valgrind can substitute its own implementation at program startup > > time. If you're statically linked against it, things will fail badly." > > ------------- > > Interesting question for FV: if a program is statically linked, and it > uses pthreads, can Valgrind handle it? V's libpthread.so won't replace > libc's, will it? None of valgrind's overrides (malloc, free etc.) will work for static programs. |
|
From: Nicholas N. <nj...@ca...> - 2004-02-18 11:12:06
|
> ------------- > "Pthreads support is improving, but there are still significant > limitations in that department. See the section above on Pthreads. Note > that your program must be dynamically linked against libpthread.so, so > that Valgrind can substitute its own implementation at program startup > time. If you're statically linked against it, things will fail badly." > ------------- Interesting question for FV: if a program is statically linked, and it uses pthreads, can Valgrind handle it? V's libpthread.so won't replace libc's, will it? N |
|
From: <js...@ac...> - 2004-02-18 04:10:40
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-02-18 04:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow fi tls.c: In function `main': tls.c:92: warning: comparison between signed and unsigned if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow -g -I../../include -MT tls2.o -MD -MP -MF ".deps/tls2.Tpo" \ -c -o tls2.o `test -f 'tls2.c' || echo './'`tls2.c; \ then mv ".deps/tls2.Tpo" ".deps/tls2.Po"; \ else rm -f ".deps/tls2.Tpo"; exit 1; \ fi gcc -Winline -Wall -Wshadow -g -I../../include -o tls -Wl,-rpath,. tls.o tls2.o tls.so -lpthread tls.so: undefined reference to `___tls_get_addr' collect2: ld returned 1 exit status make[4]: *** [tls] Error 1 make[4]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sewardj/ValgrindABT/valgrind' make: *** [check] Error 2 |
|
From: <js...@ac...> - 2004-02-18 03:56:48
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-02-18 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow then mv -f ".deps/tls.Tpo" ".deps/tls.Po"; \ else rm -f ".deps/tls.Tpo"; exit 1; \ fi if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -Winline -Wall -Wshadow -g -I../../include -MT tls2.o -MD -MP -MF ".deps/tls2.Tpo" \ -c -o tls2.o `test -f 'tls2.c' || echo './'`tls2.c; \ then mv -f ".deps/tls2.Tpo" ".deps/tls2.Po"; \ else rm -f ".deps/tls2.Tpo"; exit 1; \ fi gcc -Winline -Wall -Wshadow -g -I../../include -o tls -Wl,-rpath,. tls.o tls2.o tls.so -lpthread tls.so: undefined reference to `___tls_get_addr' collect2: ld returned 1 exit status make[4]: *** [tls] Error 1 make[4]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/sewardj/ValgrindABT/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sewardj/ValgrindABT/valgrind' make: *** [check] Error 2 |