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
(8) |
2
(8) |
3
(7) |
|
4
(3) |
5
(6) |
6
(9) |
7
(8) |
8
(7) |
9
(7) |
10
(18) |
|
11
(7) |
12
(11) |
13
(24) |
14
(13) |
15
(11) |
16
(18) |
17
(7) |
|
18
(8) |
19
(7) |
20
(9) |
21
(24) |
22
(18) |
23
(10) |
24
(7) |
|
25
(8) |
26
(11) |
27
(14) |
28
(7) |
29
(10) |
30
(7) |
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-14 18:07:45
|
CVS commit by nethercote:
Added Gtk-Gnutella.
M +2 -1 lists.html 1.5
M +3 -0 users.html 1.61
--- devel-home/valgrind/lists.html #1.4:1.5
@@ -12,5 +12,6 @@
error message, you have an idea for a new Valgrind tool and want some
feedback, etc. It is read by all the developers, plus a bunch of other
- knowledgeable folk.
+ knowledgeable folk. Unfortunately, as with any mailing list, there's no
+ guarantee that your question will be answered.
<p>
The list is mirrored at
--- devel-home/valgrind/users.html #1.60:1.61
@@ -394,4 +394,7 @@
<dd>A cross-platform Jabber client designed for the Jabber power user.
+<dt><a href="http://gtk-gnutella.sf.net/">Gtk-Gnutella</a>
+<dd>A P2P application for the Gnutella network that aims for high uptimes.
+
<dt><a href="http://www.pldaniels.com/ripmime/">ripMIME</a>
<dd>An email decoding engine and library.
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-14 14:43:38
|
On Wed, 14 Apr 2004, Jeremy Fitzhardinge wrote:
> I think _ and ... are reasonably clear as entry-matching operators,
Unfortunately, if you don't look at the manual, you won't know what they
are from context (unlike * and ? which people will likely be able to
guess... not that anyone ever uses ?). Maybe that's unavoidable.
> while * and ? work within entries. It could also be useful to match
> multiple entries with a |-like syntax:
>
> fun:malloc,
> fun:_myalloc_1 | fun:another_alloc | src:blah.c,
> fun:common
>
> (This suggests that we could also allow &:
>
> fun:foobar & src:myfoo.c, // not the other foobar()
> )
I'm wary about these -- have you seen particular cases where these would
be useful, or are you just hypothesizing? All the things I've mentioned
have come from user feedback, people saying either "I want to be able to
do this", or being confused about something. No point adding complexity
if no-one will use it.
> Also, I would prefer to avoid over-abbreviating things. Use "file:" and
> "func:" rather than fil: and fun:, since they're a bit unclear. And
> perhaps src: (and obj:) rather than file:, since file: is a bit generic
> when we have two interesting file types.
Sure.
> Another nit: use {} for grouping, since that's what the languages do.
I specifically didn't choose {} because it's used to groups statements in
procedural languages, which is not at all like a call trace. I
deliberately used [] because it's often used as list notation (eg. in
Haskell, Prolog), and a call trace can be considered exactly as a list.
> Other comments:
>
> * Some way of enabling/disabling a suppression while keeping it in
> the file and not commenting it out. This would make it a bit
> easier for tools/programs to manage the file contents
ok, any ideas how?
> * allow comments everywhere
yes
> * allow a more detailed description about the suppression, so it
> can be shown in a GUI
can you give an example?
> * matching against the soname of a .so file, rather than just the
> file name. The soname is canonical.
I don't understand what you mean by canonical here...
> * Have a consistent quoting scheme to allow quoting anywhere
> (otherwise how would we cope with someone with ',' in their
> filenames - strange, but possible); also needed as symbol names
> get more complex (ie, unmangled c++)
hmm, yes
> * Need to work out how to address mangling. Since there are
> multiple mangling schemes, we would either need to specify which
> one we want (ugly, compliler-dependent, but what we have now in
> effect, only manual), or generate matching rules for all mangled
> forms of the given c++ name. I guess some syntax like
> "mangle:int foo(void)" would do it.
I'm tempted to stick with the current system.
> * How flexible should we be with pathname matching? Do we match
> the whole pathname, or does "foo.c" mean */foo.c? i.e, should
> we pay attention to whether the specified filename contains '/'
> or not?
I think current system -- exact matches against entire paths -- seems ok.
N
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-14 09:07:29
|
On Tue, 13 Apr 2004, Robert Walsh wrote: > Well, most of these new and deletes are going to be doing some sort of > allocation and freeing at the end of the day. I can see several > scenarios: > > * custom allocator doesn't actually allocate anything. > * custom allocator allocates memory by doing a call to the glibc > version of the allocator after looking up it's address using > dlsym(RTLD_NEXT, ...). > * custom allocator allocates memory by doing a call to malloc or > some other existing allocator. > * custom allocator allocates memory using some custom mechanism, > such as a memory pool. > > In the first scenario, nothing happens. That's just weird anyway, and I > can't imagine it happening very often, but you never know. In any case, > nothing is allocated and life goes on. Valgrind won't mind at all. > > In the second scenario, the glibc allocator is eventually called, but > that call gets intercepted by Valgrind and treated as normal. This is > probably most often used for error-checking malloc wrappers and the > like. > > In the third scenario, operator new or whatever calls malloc or > something like that. This too will get intercepted by Valgrind as a > regular malloc. This is what the new_override.cpp test does. > > In the fourth scenario, everything is up in the air, but I don't see why > Valgrind should care, as long as the underlying memory allocation > mechanism is intercepted. > > If I'm forgetting anything, let me know. All sounds good to me. With the fourth scenario, they would have to use client requests as with any other custom allocator. Thanks for clearing this up for me. N |
|
From: Jeremy F. <je...@go...> - 2004-04-14 07:22:15
|
CVS commit by fitzhardinge:
Quiet an overly noisy message.
M +1 -1 vg_symtab2.c 1.77
--- valgrind/coregrind/vg_symtab2.c #1.76:1.77
@@ -214,5 +214,5 @@ void VG_(addLineInfo) ( SegInfo* si,
* multiple instructions can map to the one line), but avoid
* catching any other instructions bogusly. */
- if (this > next) {
+ if (this > next && VG_(clo_verbosity) > 2) {
VG_(message)(Vg_DebugMsg,
"warning: line info addresses out of order "
|
|
From: Jeremy F. <je...@go...> - 2004-04-14 07:19:33
|
CVS commit by fitzhardinge:
Fix for bug 77869. Names in stabs are terminated by ':'. Except templated
names, which can have :: within <> quotes. Except when it's an operator,
which can have a name like operator<, followed by ::.
M +34 -1 vg_stabs.c 1.11
--- valgrind/coregrind/vg_stabs.c #1.10:1.11
@@ -403,4 +403,22 @@ static UInt atou(Char **pp, Int base)
}
+static Bool isoperator(Char op)
+{
+ switch(op) {
+ case 'a'...'z':
+ case 'A'...'Z':
+ case '0'...'9':
+ case '_':
+ case ':':
+ case '\'':
+ case '"':
+ case '$':
+ return False;
+
+ default:
+ return True;
+ }
+}
+
/* Skip a ':'-delimited name which may have ::, 'char' or other things in
<> brackets */
@@ -409,4 +427,16 @@ static Char *templ_name(Char *p)
Int brac = 0;
+ /* Special case: if the name is "operatorX", where X is not an
+ otherwise valid operator name, then just skip to the terminating
+ ':' and ignore the '<>' bracketing stuff. That's because names
+ like "operator<" and "operator<=" can appear here, and it can be
+ terminated by ::. */
+ if (VG_(strncmp)(p, "operator", 8) == 0 && isoperator(p[8])) {
+ p += 8;
+ while(*p != ':')
+ p++;
+ return p;
+ }
+
for(;;) {
if (*p == '<')
@@ -424,6 +454,9 @@ static Char *templ_name(Char *p)
if (brac && p[0] == '\'' && p[2] == '\'')
p += 3;
+
+ /* If we're within <>, then treat :: as part of the name (a single
+ : still terminates) */
if (*p == ':') {
- if (brac && p[1] == ':')
+ if (brac && p[1] == ':' && p[-1] != '<')
p++;
else
|
|
From: Jeremy F. <je...@go...> - 2004-04-14 05:32:49
|
On Tue, 2004-04-13 at 20:09, Nicholas Nethercote wrote:
> -----------------------------------------------------------------------------
> possible new syntax
> -----------------------------------------------------------------------------
>
> Memcheck,Addrcheck:Addr4("this is the name of it")[optional part?]
> [
> fun:blahblah,
> fil:foobar,
> ..., multi-matching wildcard?
> obj:foo*,
> _, single-matching wildcard?
> obj:floo
> ]
>
> - name as string gives a clue that it's arbitrary
> - commas after trace lines indicate they're part of a sequence, as does
> grouping them together within the brackets, as does (maybe) the
> use of square brackets
> - different roles of different parts much clearer
> - ... gives more flexibility; the different meanings of "..." vs. '*'/'?'
> wildcards should be clear XXX: really?
I think _ and ... are reasonably clear as entry-matching operators,
while * and ? work within entries. It could also be useful to match
multiple entries with a |-like syntax:
fun:malloc,
fun:_myalloc_1 | fun:another_alloc | src:blah.c,
fun:common
(This suggests that we could also allow &:
fun:foobar & src:myfoo.c, // not the other foobar()
)
Also, I would prefer to avoid over-abbreviating things. Use "file:" and
"func:" rather than fil: and fun:, since they're a bit unclear. And
perhaps src: (and obj:) rather than file:, since file: is a bit generic
when we have two interesting file types.
Another nit: use {} for grouping, since that's what the languages do.
Other comments:
* Some way of enabling/disabling a suppression while keeping it in
the file and not commenting it out. This would make it a bit
easier for tools/programs to manage the file contents
* allow comments everywhere
* allow a more detailed description about the suppression, so it
can be shown in a GUI
* matching against the soname of a .so file, rather than just the
file name. The soname is canonical.
* Have a consistent quoting scheme to allow quoting anywhere
(otherwise how would we cope with someone with ',' in their
filenames - strange, but possible); also needed as symbol names
get more complex (ie, unmangled c++)
* Need to work out how to address mangling. Since there are
multiple mangling schemes, we would either need to specify which
one we want (ugly, compliler-dependent, but what we have now in
effect, only manual), or generate matching rules for all mangled
forms of the given c++ name. I guess some syntax like
"mangle:int foo(void)" would do it.
* How flexible should we be with pathname matching? Do we match
the whole pathname, or does "foo.c" mean */foo.c? i.e, should
we pay attention to whether the specified filename contains '/'
or not?
J
|
|
From: <js...@ac...> - 2004-04-14 03:34:19
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-04-14 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 152 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-04-14 03:07:26
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-04-14 04:00:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 152 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-04-14 02:23:10
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-04-14 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 1 stderr failure, 1 stdout failure ================= helgrind/tests/inherit (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-14 02:18:05
|
Nightly build on audi ( Red Hat 9 ) started at 2004-04-14 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 1 stderr failure, 0 stdout failures ================= helgrind/tests/inherit (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-14 02:13:21
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-04-14 03:10:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 6 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-14 02:08:23
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-04-14 03:05:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 6 stderr failures, 1 stdout failure ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-14 02:06:39
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-04-14 03:00:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 2 stderr failures, 0 stdout failures ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |