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: Tom H. <to...@co...> - 2005-03-02 23:54:37
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Wed, 2 Mar 2005, Tom Hughes wrote:
>
> > Stabs is just horrible basically, so we should do our best and then
> > give up if necessary. If people want reliable debugging they should
> > be using DWARF anyway - it's the default from gcc 3 onwards on linux
> > so we should see less and less stabs I guess.
>
> Doesn't MacOS X use stabs?
Oh it may be an issue on other systems, but we'll just have to do
the best that we can.
The main problem is that there was never a formal specification for
stabs in the first place and over the years each compiler vendor has
extended the undocumented format with undocumented extensions as
new language features have appeared.
The best documentation that I'm aware is the reverse engineered
attempt at documenting all the various extensions at:
http://sources.redhat.com/cygwin/stabs.html
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-03-02 23:51:10
|
In message <422...@go...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Tom Hughes wrote:
>
> >I'm not sure that there is any ambiguity actually. I went through it
> >quite carefully and looked at what gdb was doing and more or less
> >convinced myself that you can always work it out, but you do need to
> >use different algorithms for each of the three cases.
> >
> >As of my last change we should hopefully be doing the same as gdb
> >and all the test cases I had were fixed, but several of the bugs had
> >no test case. They're still open because none of the submitters came
> >back and confirmed if my patch had fixed the problem but I did commit
> >it anyway.
>
> I don't remember all the details, but I seem to remember that there was
> ambiguity around the various meanings of ':', and whether they're
> bracketed by '<>' or not.
That is the main problem, but if you analyse it carefully there are
some cases where :: can only occur inside <> so if you see : at the
top leel you know it is the fields separator. In other cases it can
occur at the top level but you can never get a colon at the start of
the next field so you know that a double colon doesn't end the field
but a single one does.
This is the commit log entry I wrote when I committed the patch to
try and explain the various cases:
: Try and improve the parsing of C++ stabs that contain :: sequences. This
: patch attempts to follow the same rules that gdb uses and is based on the
: fact that there appear to be three places where :: can appear:
:
: - In the name of a undefined struct/union/enum after an x type
: marker. In this case we follow a simplified version of the old
: rules and only allow :: inside <> characters.
:
: - In a method name. These are mangled so :: will never appear as
: part of the name but will always occurs as the terminator. We
: handle this by stopping at the first :: sequence.
:
: - In a symbol/type name. This can include :: but can only be ended
: by a single colon so we simply carry on until we see that.
:
: I suspect this will resolve a number of bugs but I'm still waiting for
: the submitters to confirm exactly which ones it resolves.
> Plus there's a definite bug in the handling of template classes which
> have chars (any maybe strings?) as template parameters: it just plonks
> the character literally in the stab info, even if its something like \0
> (ie, it puts a literal 0x0 in the stabs string).
That I can believe but I haven't seen that one come up yet...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-02 23:41:00
|
CVS commit by nethercote: memory wibble M +3 -2 valgrind-quick-start 1.4 --- devel-home/valgrind/valgrind-quick-start #1.3:1.4 @@ -31,6 +31,7 @@ option turns on the memory leak detector. -Your program will run much slower (eg. 20 to 30 times) than normal. -Memcheck will issue messages about memory errors and leaks that it detects. +Your program will run much slower (eg. 20 to 30 times) than normal, and use +a lot more memory. Memcheck will issue messages about memory errors and +leaks that it detects. |
|
From: Nicholas N. <nj...@cs...> - 2005-03-02 23:29:19
|
On Wed, 2 Mar 2005, Tom Hughes wrote: > Stabs is just horrible basically, so we should do our best and then > give up if necessary. If people want reliable debugging they should > be using DWARF anyway - it's the default from gcc 3 onwards on linux > so we should see less and less stabs I guess. Doesn't MacOS X use stabs? N |
|
From: Nicholas N. <nj...@cs...> - 2005-03-02 23:28:58
|
On Wed, 2 Mar 2005, Jeremy Fitzhardinge wrote: > This one is reasonably easy to fix, I think. > >> 88116 "enter" instruction's nested variation not supported >> 96542 Assertion vg_assert(sz == 4) failed in vg_to_ucode > > As are these. I don't think 88116 is -- the nested variations are really awful. But they're also incredibly rare, thankfully. >> 80932 valgrind: vg_memory.c:757 (vgPlain_init_shadow_range): As... > > This is just a client-stomps-on-Valgrind problem, assuming --pointercheck was > off. But we don't yet know for sure that --pointercheck was off. Maybe something weird is happening. N |
|
From: Jeremy F. <je...@go...> - 2005-03-02 22:52:09
|
Tom Hughes wrote:
>In message <422...@go...>
> Jeremy Fitzhardinge <je...@go...> wrote:
>
>
>
>>Nicholas Nethercote wrote:
>>
>>
>>
>>>-----------------------------------------------------------------------------
>>>
>>>debug info reading
>>>-----------------------------------------------------------------------------
>>>
>>> ?78520 bug parsing gstabs+ debug syms for c++ templates
>>> ?81262 valgrind crashes with "the `impossible' happened" <- don'...
>>> 89914 seg fault analyzing programs compiled with gnu pascal 20...
>>> ?89973 seg fault parsing stabs debug information
>>> 90901 Valgrind is very-very slow
>>> ?91633 dereference of null ptr in vgPlain_st_basetype
>>>* 92071 Reading debugging info uses too much memory
>>> ?95867 get SIGSEGV when running my code under valgrind (compile ...
>>> 96918 Hit maxsyms limit in VG_(get_scope_variables)
>>>
>>>
>>For 78520, 81262, 89973 and 95867 the basic problem is that the stabs
>>encoding for C++ types is not well defined, and is basically ambigious.
>>
>>
>
>I'm not sure that there is any ambiguity actually. I went through it
>quite carefully and looked at what gdb was doing and more or less
>convinced myself that you can always work it out, but you do need to
>use different algorithms for each of the three cases.
>
>As of my last change we should hopefully be doing the same as gdb
>and all the test cases I had were fixed, but several of the bugs had
>no test case. They're still open because none of the submitters came
>back and confirmed if my patch had fixed the problem but I did commit
>it anyway.
>
>
I don't remember all the details, but I seem to remember that there was
ambiguity around the various meanings of ':', and whether they're
bracketed by '<>' or not.
Plus there's a definite bug in the handling of template classes which
have chars (any maybe strings?) as template parameters: it just plonks
the character literally in the stab info, even if its something like \0
(ie, it puts a literal 0x0 in the stabs string).
>When everything is a bit more stable I'll probably look at whether
>we can switch to using libdwarf which should make it a lot easier
>to add the missing functionality to the DWARF reader and also give
>us incremental loading I believe.
>
Good.
J
|
|
From: Tom H. <to...@co...> - 2005-03-02 19:54:46
|
In message <422...@go...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Nicholas Nethercote wrote:
>
> > -----------------------------------------------------------------------------
> >
> > debug info reading
> > -----------------------------------------------------------------------------
> >
> > ?78520 bug parsing gstabs+ debug syms for c++ templates
> > ?81262 valgrind crashes with "the `impossible' happened" <- don'...
> > 89914 seg fault analyzing programs compiled with gnu pascal 20...
> > ?89973 seg fault parsing stabs debug information
> > 90901 Valgrind is very-very slow
> > ?91633 dereference of null ptr in vgPlain_st_basetype
> > * 92071 Reading debugging info uses too much memory
> > ?95867 get SIGSEGV when running my code under valgrind (compile ...
> > 96918 Hit maxsyms limit in VG_(get_scope_variables)
>
> For 78520, 81262, 89973 and 95867 the basic problem is that the stabs
> encoding for C++ types is not well defined, and is basically ambigious.
I'm not sure that there is any ambiguity actually. I went through it
quite carefully and looked at what gdb was doing and more or less
convinced myself that you can always work it out, but you do need to
use different algorithms for each of the three cases.
As of my last change we should hopefully be doing the same as gdb
and all the test cases I had were fixed, but several of the bugs had
no test case. They're still open because none of the submitters came
back and confirmed if my patch had fixed the problem but I did commit
it anyway.
> There's stuff which simply isn't possible to represent in stabs, but
> that doesn't mean the compiler won't try. The correlated problem is
> that stabs parsing is pretty fragile; once you lose track of what's
> going on, you pretty much have to give up. Clearly Valgrind needs to be
> robust against this junk, but we're not actually going to be able to
> close all these bugs (we should do what gdb does, and just silently
> ignore bad debug, so the user need never know...).
Stabs is just horrible basically, so we should do our best and then
give up if necessary. If people want reliable debugging they should
be using DWARF anyway - it's the default from gcc 3 onwards on linux
so we should see less and less stabs I guess.
> For DWARF, I think we can get large time and memory savings by using
> incremental loading.
When everything is a bit more stable I'll probably look at whether
we can switch to using libdwarf which should make it a lot easier
to add the missing functionality to the DWARF reader and also give
us incremental loading I believe.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeremy F. <je...@go...> - 2005-03-02 19:10:05
|
Nicholas Nethercote wrote: > ----------------------------------------------------------------------------- > > JIT shortcomings > ----------------------------------------------------------------------------- > > * 69511 Valgrind can call wrong function I thought of a pretty simple fix for this; see bug. > * 69530 we need to implement precise exception handling > * 69531 Some tools need a mechanism to save machine state before ... I think these are basically the same. Vex has precise exceptions with memory accesses, which will solve a large part of this problem; I don't think it has precise (or any) FP exceptions. > * 81361 Can't distinguish large stack allocations from stack-swit... I've got a solution for this too. Not really a JIT problem as such. > 82654 prefetch instructions are ignored > 85756 x86 assembly prefix LOCK to guarantee atomicity has no ef... This would be nice to have. Now that we're using native pthreads, people are going to start trying to use system-scope mutexes, etc, which will probably break badly for them. > ----------------------------------------------------------------------------- > > JIT bugs > ----------------------------------------------------------------------------- > > 87263 Assertion `seg_selector >= 6 && seg_selector < (6 + 3)' f... This one is reasonably easy to fix, I think. > 88116 "enter" instruction's nested variation not supported > 96542 Assertion vg_assert(sz == 4) failed in vg_to_ucode As are these. > 97231 Jump to the invalid address stated on the next line > 100486 memcheck reports "valgrind: the `impossible' happened: V... I think these are the same bug, and probably fixed. I suspect they were actually signal handling bugs. > ----------------------------------------------------------------------------- > > debug info reading > ----------------------------------------------------------------------------- > > ?78520 bug parsing gstabs+ debug syms for c++ templates > ?81262 valgrind crashes with "the `impossible' happened" <- don'... > 89914 seg fault analyzing programs compiled with gnu pascal 20... > ?89973 seg fault parsing stabs debug information > 90901 Valgrind is very-very slow > ?91633 dereference of null ptr in vgPlain_st_basetype > * 92071 Reading debugging info uses too much memory > ?95867 get SIGSEGV when running my code under valgrind (compile ... > 96918 Hit maxsyms limit in VG_(get_scope_variables) For 78520, 81262, 89973 and 95867 the basic problem is that the stabs encoding for C++ types is not well defined, and is basically ambigious. There's stuff which simply isn't possible to represent in stabs, but that doesn't mean the compiler won't try. The correlated problem is that stabs parsing is pretty fragile; once you lose track of what's going on, you pretty much have to give up. Clearly Valgrind needs to be robust against this junk, but we're not actually going to be able to close all these bugs (we should do what gdb does, and just silently ignore bad debug, so the user need never know...). For stabs, a streaming loader will definitely help cap memory use, though of course our parsed structures will take the same amount of space. For DWARF, I think we can get large time and memory savings by using incremental loading. > ----------------------------------------------------------------------------- > > misc crashes/asserts > ----------------------------------------------------------------------------- > > 73133 old versions of glibc can't handle auxv types >=32 > 80932 valgrind: vg_memory.c:757 (vgPlain_init_shadow_range): As... This is just a client-stomps-on-Valgrind problem, assuming --pointercheck was off. > ?87645 ASSERT `vgPlain_is_valid_tid(vg_tid_last_in_baseBlock)' f... > 88192 dlsym(...,"errno") fails under valgrind on RH-9.0 > 91601 INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) > ?96559 Received "INTERNAL ERROR: Valgrind received a signal 11 (... > > ----------------------------------------------------------------------------- > > suppressions > ----------------------------------------------------------------------------- > > 89996 supp file for libguile > 91153 Possible new leak to suppress in glibc-2.?.supp > 91197 Annoying user confirmation required with --gen-suppressio... Also "93376 <http://bugs.kde.org/show_bug.cgi?id=93376>: Suppressions directory" seems like a good idea to me. > > ----------------------------------------------------------------------------- > > memcheck, Cachegrind, Helgrind > ----------------------------------------------------------------------------- > > 97042 valgrind problems with subl $0x80000000, %reg [Vex] > 90838 debugging aisexec: cannot get simulation results > 79844 Helgrind complains about race condition which does not exist > > ----------------------------------------------------------------------------- > > GDB attaching > ----------------------------------------------------------------------------- > > 88842 --db-attach=yes problem with --log-file > ?95896 enter gdb option doesn't work for my stty -raw application gdb stub support might be the best fix for these. > ----------------------------------------------------------------------------- > > misc > ----------------------------------------------------------------------------- > > 79759 error reports when running programs copiled with g++ with... > ?80946 lots of false errors due to incomplete str* intercepts > 85050 Full source path not logged This one is simply that the debug info doesn't always include a full path, I think. It would be pretty messy to print it all the time as well... > 88678 Empty stack trace for executables with a space in the path > 90348 vg_mylibc.c:668 (vgPlain_sprintf): Assertion `vgPlain_str... > 92923 lit_to_globvar broken > 96321 make check fails with hardened gcc > 97452 Valgrind doesn't report any pthreads problems > 98444 valgrind fails to run against user-mode-linux (UML) proce... I think this just comes down to bug 81361. > 98071 valgrind bombs out when sdl is linked > 98290 Valgrind internals need annotating > 100428 compile failure in coregrind vg_pthreadmodel > > ----------------------------------------------------------------------------- > > 8 most important, IMHO > ----------------------------------------------------------------------------- > > * 69511 Valgrind can call wrong function > * 69530 we need to implement precise exception handling > * 69531 Some tools need a mechanism to save machine state before ... > * 81361 Can't distinguish large stack allocations from stack-swit... > * 82301 FV memory layout too rigid > * 92071 Reading debugging info uses too much memory > * 93818 couldn't allocate address space for shadow memory > * 98278 Infinite recursion possible when allocating memory > > > Comments: > - Of the eight most important, 4 are in the JIT, and they're just hard > problems. It's not easy to see how to fix these without hurting > performance really badly. And the other two JIT shortcomings are > arguably > very important too. I added some comments to bugs 69511 and 81361; they both seem tractable. I'm pretty sure 69530 and 69531 are the same bug (specially now that the BB has been removed). > ----------------------------------------------------------------------------- > > suppressions > ----------------------------------------------------------------------------- > > 73309 Ignore duplicate reports when prompting for generating su... > * 77922 Honour error suppression call lists longer than 4 functions. > * 79787 Suppresions files should be auto generated > 93376 Suppressions directory 93376 is worth a * I think. > ----------------------------------------------------------------------------- > > error messages > ----------------------------------------------------------------------------- > > 75104 Would like option to suppress output of stack addresses > 79311 malloc silly arg warning does not give stack trace > * 79362 Debug info is lost for .so files when they are dlclose'd > 82176 loss records with parameters > 92036 A wish for ANSI Colors in the output of valgrind > 98993 Option to show addresses of recently executed basic blocks 98993 would allow a class of "wild jumping through pointer" bugs to be easily fixable; at present they're very hard to debug by any means. > ----------------------------------------------------------------------------- > > leak checking > ----------------------------------------------------------------------------- > > 74899 Tracking leaks in real time > 81079 Provide a macro to clear leak list 81079 is a fairly small extension to the leak checker. It just needs another bit per allocated heap block. > > ----------------------------------------------------------------------------- > > massif > ----------------------------------------------------------------------------- > > 89707 alloc-fn appears not to work for C++ class member functions This a more general wishlist item, which is "should be able to use unmangled names when referring to C++ methods/functions". > 92615 Write output from Massif at crash > 95483 massif feature request: include peak allocation in report > > ----------------------------------------------------------------------------- > > misc > ----------------------------------------------------------------------------- > > 84348 Support linuxthreads_db? This is related to the other gdb-attach bugs, and is fixable by implementing the gdb remote protocol (which I have a solid beginning of). > 87000 Macros to start/stop/restart logging > 92336 speedup re-build after few changes > 92456 Tracing the origin of uninitialised memory > 93673 request for memory limits > 97361 Better ~/.valgrindrc ( # comments, multi argument options) > > ----------------------------------------------------------------------------- > > 2 most important, IMHO > ----------------------------------------------------------------------------- > > * 75247 x86_64/amd64 support > * 77922 Honour error suppression call lists longer than 4 functions. > * 79362 Debug info is lost for .so files when they are dlclose'd > * 79787 Suppresions files should be auto generated (for large values of 2) Yes, these looks good. I think the 3 I mentioned, 93376, 98993 and 81079, are pretty useful. 98993 (show recent BBs) will require codegen support, so that's definitely post-merge. The suppressions directory will become particularly useful as people use more suppressions; I would imagine that a large project would have its own suppressions directory (or even one per subsystem), and people would put things into it/them as required. A lot nicer than editing a single file, or having lots of individual suppression files listed on the command line. Great job Nick. This really helps put everything into perspective. J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-02 17:00:29
|
Hi, I've trawled through Bugzilla, and categorised all our bugs and wishlist reports. Details are below. The aim was to identify which parts of Valgrind are causing us grief, based on real user feedback... a bit like an indirect survey. I've done some brief analysis, but I'm hoping to prompt some discussion, basically. An extremely brief summary is: - The JIT suffers some fundamental problems that are worrying and hard to fix, even with Vex - Our debug info reader sucks - Suppressions, as implemented, suck, and could be improved Happy reading. N ============================================================================= BUGS ============================================================================= The status of those marked with a '?' is unclear, eg. they might have been fixed but the original reporter hasn't confirmed it, or there's a patch but it's unclear if the patch works/has been committed. Those marked with a '*' are those that I think are the most important. ----------------------------------------------------------------------------- JIT shortcomings ----------------------------------------------------------------------------- * 69511 Valgrind can call wrong function * 69530 we need to implement precise exception handling * 69531 Some tools need a mechanism to save machine state before ... * 81361 Can't distinguish large stack allocations from stack-swit... 82654 prefetch instructions are ignored 85756 x86 assembly prefix LOCK to guarantee atomicity has no ef... ----------------------------------------------------------------------------- JIT bugs ----------------------------------------------------------------------------- 87263 Assertion `seg_selector >= 6 && seg_selector < (6 + 3)' f... 88116 "enter" instruction's nested variation not supported 96542 Assertion vg_assert(sz == 4) failed in vg_to_ucode 97231 Jump to the invalid address stated on the next line 100486 memcheck reports "valgrind: the `impossible' happened: V... ----------------------------------------------------------------------------- debug info reading ----------------------------------------------------------------------------- ?78520 bug parsing gstabs+ debug syms for c++ templates ?81262 valgrind crashes with "the `impossible' happened" <- don'... 89914 seg fault analyzing programs compiled with gnu pascal 20... ?89973 seg fault parsing stabs debug information 90901 Valgrind is very-very slow ?91633 dereference of null ptr in vgPlain_st_basetype * 92071 Reading debugging info uses too much memory ?95867 get SIGSEGV when running my code under valgrind (compile ... 96918 Hit maxsyms limit in VG_(get_scope_variables) ----------------------------------------------------------------------------- resource management/conflicts ----------------------------------------------------------------------------- 73146 Can't increase file descriptor space (valgrind reserved fds) * 82301 FV memory layout too rigid ?89199 aio_write causes valgrind to hang * 93818 couldn't allocate address space for shadow memory * 98278 Infinite recursion possible when allocating memory 100628 leak-check gets assertion failure when using VALGRIND_MALLOCLIKE... ----------------------------------------------------------------------------- Massif ----------------------------------------------------------------------------- 82871 Massif output function names too short 89061 Massif: ms_main.c:485 (get_XCon): Assertion `xpt->max_chi... 89928 Massif Aborting with failure get_XCon ----------------------------------------------------------------------------- misc crashes/asserts ----------------------------------------------------------------------------- 73133 old versions of glibc can't handle auxv types >=32 80932 valgrind: vg_memory.c:757 (vgPlain_init_shadow_range): As... ?87645 ASSERT `vgPlain_is_valid_tid(vg_tid_last_in_baseBlock)' f... 88192 dlsym(...,"errno") fails under valgrind on RH-9.0 91601 INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) ?96559 Received "INTERNAL ERROR: Valgrind received a signal 11 (... ----------------------------------------------------------------------------- suppressions ----------------------------------------------------------------------------- 89996 supp file for libguile 91153 Possible new leak to suppress in glibc-2.?.supp 91197 Annoying user confirmation required with --gen-suppressio... ----------------------------------------------------------------------------- memcheck, Cachegrind, Helgrind ----------------------------------------------------------------------------- 97042 valgrind problems with subl $0x80000000, %reg [Vex] 90838 debugging aisexec: cannot get simulation results 79844 Helgrind complains about race condition which does not exist ----------------------------------------------------------------------------- GDB attaching ----------------------------------------------------------------------------- 88842 --db-attach=yes problem with --log-file ?95896 enter gdb option doesn't work for my stty -raw application ----------------------------------------------------------------------------- misc ----------------------------------------------------------------------------- 79759 error reports when running programs copiled with g++ with... ?80946 lots of false errors due to incomplete str* intercepts 85050 Full source path not logged 88678 Empty stack trace for executables with a space in the path 90348 vg_mylibc.c:668 (vgPlain_sprintf): Assertion `vgPlain_str... 92923 lit_to_globvar broken 96321 make check fails with hardened gcc 97452 Valgrind doesn't report any pthreads problems 98444 valgrind fails to run against user-mode-linux (UML) proce... 98071 valgrind bombs out when sdl is linked 98290 Valgrind internals need annotating 100428 compile failure in coregrind vg_pthreadmodel ----------------------------------------------------------------------------- 8 most important, IMHO ----------------------------------------------------------------------------- * 69511 Valgrind can call wrong function * 69530 we need to implement precise exception handling * 69531 Some tools need a mechanism to save machine state before ... * 81361 Can't distinguish large stack allocations from stack-swit... * 82301 FV memory layout too rigid * 92071 Reading debugging info uses too much memory * 93818 couldn't allocate address space for shadow memory * 98278 Infinite recursion possible when allocating memory Comments: - Of the eight most important, 4 are in the JIT, and they're just hard problems. It's not easy to see how to fix these without hurting performance really badly. And the other two JIT shortcomings are arguably very important too. And the other four all have to do with memory layout. Hopefully Julian's ideas about 64MB blocks can fix these; that would be great. - Our debug info reading is kind of sucky, although it's improved a lot thanks to Tom and Jeremy's work. But I think it's now ready for an overhaul: to be neater, and to support incremental reading, which would help with the memory layout issues. - Massif needs a re-write. It's currently too fragile, the data structures are too complex and hard to understand, and it's hard to verify it's doing the right thing. It's on my long-term todo list, but I'm not even sure how to go about it yet. - There are happily few bugs involving signals/pthreads/the scheduler. Before Jeremy fixed that stuff, there were heaps. So that's great. (We're down to about 57 bugs now, whereas at one point we were closer to 90.) ============================================================================= WISHLIST ============================================================================= ----------------------------------------------------------------------------- suppressions ----------------------------------------------------------------------------- 73309 Ignore duplicate reports when prompting for generating su... * 77922 Honour error suppression call lists longer than 4 functions. * 79787 Suppresions files should be auto generated 93376 Suppressions directory ----------------------------------------------------------------------------- error messages ----------------------------------------------------------------------------- 75104 Would like option to suppress output of stack addresses 79311 malloc silly arg warning does not give stack trace * 79362 Debug info is lost for .so files when they are dlclose'd 82176 loss records with parameters 92036 A wish for ANSI Colors in the output of valgrind 98993 Option to show addresses of recently executed basic blocks ----------------------------------------------------------------------------- ports ----------------------------------------------------------------------------- * 75247 x86_64/amd64 support ----------------------------------------------------------------------------- new tools/greatly extended tools ----------------------------------------------------------------------------- 75999 Valgrind tool should also include functionality of code c... 76510 way to measure working set size? 81917 Request for Feature - maps of variable locations in cache... 84303 How about a LockCheck tool? 93498 Request for implementing SIDT instruction 95261 provide a library to write cachegrind-like tools 96109 Support for CMP architecture in Valgrind ( cachegrind ) ----------------------------------------------------------------------------- leak checking ----------------------------------------------------------------------------- 74899 Tracking leaks in real time 81079 Provide a macro to clear leak list ----------------------------------------------------------------------------- massif ----------------------------------------------------------------------------- 89707 alloc-fn appears not to work for C++ class member functions 92615 Write output from Massif at crash 95483 massif feature request: include peak allocation in report ----------------------------------------------------------------------------- misc ----------------------------------------------------------------------------- 84348 Support linuxthreads_db? 87000 Macros to start/stop/restart logging 92336 speedup re-build after few changes 92456 Tracing the origin of uninitialised memory 93673 request for memory limits 97361 Better ~/.valgrindrc ( # comments, multi argument options) ----------------------------------------------------------------------------- 2 most important, IMHO ----------------------------------------------------------------------------- * 75247 x86_64/amd64 support * 77922 Honour error suppression call lists longer than 4 functions. * 79362 Debug info is lost for .so files when they are dlclose'd * 79787 Suppresions files should be auto generated Comments: - AMD64 support is going well, so that's not a problem. (Nb: that report has 440 votes associated with it; no other open report has more than 40!) - Suppressions kind of suck in general: the syntax is too hard to get right, not flexible enough; the auto-generation is not convenient enough to use; and they only support a stack trace four deep. I plan to address the stack depth issue when I change --num-callers to a larger value. Fixing the other problems is on my long-term todo list. - The debug info getting lost is a problem for the leak checker. I think the right way to fix this is to record code locations as either source locations (eg. file/fn/line) if possible, or as object code locations (eg. file/offset). Recording them as locations in memory is no good, since they can change over time. But I recall some argument about this in the past. - Massif comes up again. I think people tend to project their wishes for a memory-measurement tool onto it, even when what they want isn't very close to what Massif currently does. |
|
From: Jeremy F. <je...@go...> - 2005-03-02 08:26:05
|
CVS commit by fitzhardinge:
Add a test case for creating and destroying lots of threads.
A manythreads.c 1.1 [no copyright]
A manythreads.stderr.exp 1.1
A manythreads.stdout.exp 1.1
A manythreads.vgtest 1.1
M +4 -0 Makefile.am 1.64
--- valgrind/none/tests/Makefile.am #1.63:1.64
@@ -31,4 +31,5 @@
getseg.stdout.exp getseg.stderr.exp getseg.vgtest \
gxx304.stderr.exp gxx304.vgtest \
+ manythreads.stdout.exp manythreads.stderr.exp manythreads.vgtest \
map_unaligned.stderr.exp map_unaligned.vgtest \
map_unmap.stderr.exp map_unmap.stdout.exp map_unmap.vgtest \
@@ -68,4 +69,5 @@
discard exec-sigmask execve faultstatus fcntl_setown floored fork \
fucomip getseg \
+ manythreads \
munmap_exe map_unaligned map_unmap mq mremap rcrl readline1 \
resolv rlimit_nofile selfrun sem semlimit sha1_test \
@@ -143,4 +145,6 @@
# pthread C ones
+manythreads_SOURCES = manythreads.c
+manythreads_LDADD = -lpthread
pth_blockedsig_SOURCES = pth_blockedsig.c
pth_blockedsig_LDADD = -lpthread
|
|
From: <js...@ac...> - 2005-03-02 04:00:56
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-02 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 ---------------------------------------- == 208 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-02 03:28:32
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-02 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 ---------------------------------------- == 215 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-02 03:22:46
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-02 03:15:02 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 ---------------------------------------- == 214 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: Tom H. <th...@cy...> - 2005-03-02 03:15:41
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-02 03:00:02 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 ---------------------------------------- == 213 tests, 11 stderr failures, 0 stdout failures ================= addrcheck/tests/leak-tree (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/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-02 03:11:54
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-02 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) 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) make: *** [regtest] Error 1 |