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
|
|
2
|
3
|
4
|
5
(2) |
6
(1) |
7
|
8
|
|
9
(1) |
10
(1) |
11
|
12
|
13
|
14
(3) |
15
(4) |
|
16
(4) |
17
(2) |
18
(18) |
19
|
20
|
21
(7) |
22
|
|
23
(2) |
24
(3) |
25
(1) |
26
(5) |
27
(12) |
28
(1) |
29
(2) |
|
30
(4) |
31
|
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2003-03-18 23:28:14
|
On Tue, 2003-03-18 at 14:31, Eyal Lebedinsky wrote:
> Another confusing point: I see identical functions defined in
> different
> contexts, like VG_(do_syscall2) in general and my_do_syscall2 in
> vg_mylibsc.c. Is there a need for vg_mylibc.c to be independent?
Syscalls are special, because they require values to be placed in
particular registers. They're static or inline, mainly so they can get
the registers they need. There's a bug in that valgrind is compiled
without -fpic despite being a shared object; the problem is that -fpic
makes it hard for the syscall functions to get the registers they need.
I poked at it for a while, but didn't come up with a nice enough
solution to show off.
Obviously the problem is solvable, because glibc does it.
J
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 22:46:53
|
On Wed, 19 Mar 2003, Eyal Lebedinsky wrote: > OK, this is good. However, I still am unclear on a few idioms in vg. > > e.g., when adding to vg_mylibs.c I see some functions are defines as > Int my_connect (... > while others use > Int VG_(write_socket)(... Are you referring to the use of the VG_ prefix? If so, we use it on any non-static (ie. globally visible) symbols. Since Valgrind shares the same namespace as the client program, at least from the point of view of the dynamic linker, Valgrind and skins shouldn't define any global symbols without VG_ or SK_ or similar prefixes, to minimise the chances of name clashes. It's not necessary for static (ie. local) symbols. (Note that VG_(foo) is just short for vgPlain_foo, that SK_(foo) is just short for vgSkin_foo, etc.) > Another confusing point: I see identical functions defined in different > contexts, like VG_(do_syscall2) in general and my_do_syscall2 in > vg_mylibsc.c. Is there a need for vg_mylibc.c to be independent? I don't see VG_(do_syscall2)() anywhere. But vg_mylibc.c:vg_do_syscall2() is very similar to vg_libpthread.c:my_do_syscall2(). Perhaps the latter could be removed. But they are slightly different, which may be important. Not sure. N |
|
From: Eyal L. <ey...@ey...> - 2003-03-18 22:31:49
|
> Jeremy Fitzhardinge wrote: > > On Tue, 2003-03-18 at 04:37, Eyal Lebedinsky wrote: > > > '%d' is good for 'int', what is the correct one for 'Int'? If I > > use '%ld' then I violated the type hiding. In C this is a problem > > and for this reason I prefer to use basic types wherever I can, and > > typedef only where actually necessary. > > > No. VG_(message) is a Valgrind-internal function, so it is defined in > terms of Int, Char, etc, including the interpretation of %d. %ld is > for Long, which is 64 bits. OK, this is good. However, I still am unclear on a few idioms in vg. e.g., when adding to vg_mylibs.c I see some functions are defines as Int my_connect (... while others use Int VG_(write_socket)(... Another confusing point: I see identical functions defined in different contexts, like VG_(do_syscall2) in general and my_do_syscall2 in vg_mylibsc.c. Is there a need for vg_mylibc.c to be independent? Attached in a patch that uses the abstracted types exclusively. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 19:19:33
|
Hi,
I've just hacked up support for automatic suppression generation. If
everyone likes it, I will commit it to the HEAD.
Some notes:
- option name is --gen-suppressions=yes which is maybe too long...
maybe --gen-supps=yes would be better
- it required two new functions, SK_(get_error_name)() and
SK_(print_extra_suppression_info)(), which must be defined by skins
using the ``skin_errors'' need.
A skin can be lazy and not support automatic generation of
suppressions by returning NULL from SK_(get_error_name)().
Alternatively, it can choose to support it for only a subset
of all error kinds -- eg. Memcheck doesn't support suppression of
`User' errors.
- upon each error, the user is prompted if they want the suppression to
be generated, a la the GDB attachment prompting
- the generated suppressions look like this:
{
<insert a suppression name here>
Memcheck:Addr1
fun:ddd
fun:bbb
fun:aaa
}
I could change it so the title is eg. ddd/bbb/aaa, but I like the
"<insert suppression name here>" better, since it emphasises that the
user can choose the name. Also the code is easier :) Besides, I
think the ddd/bbb/aaa confuses users a lot already... outputting that
might make users think the name important (when it's really only used
with -v) or that it has to have the x/y/z structure, or something.
- I just print out the suppression to stderr. It could be done more
fancily, eg. by appending the suppressions to a specified file or
something, but I think cut+paste is good enough. In my testing, I
found it quite agreeable. But others may disagree.
- Getting it working with leak checking required a bit of ugly hackery,
but then, leak suppressions were already pretty ugly, since they
don't use the general error recording mechanisms. I had to add
a "LeakErr" error type. (The leak checker should really be in the
MemCheck skin, not in core...[sigh])
- I've tested it reasonably thoroughly with Memcheck and Addrcheck...
among other things, I was able to correctly suppress the 10 value/addr
errors and a whole bunch of leaks that my (pre KDE 3) version of
Konqueror was emitting, so it seems to be working fairly well.
- I've even updated the documentation, including fixing a few minor
bugs in other unrelated parts.
Note that the section on writing suppression files has disappeared in
the v1.9.X docs! This is bad.
Also, the guide to writing skins isn't included.
I think this patch is extremely useful, _especially_ since I just
discovered that C++ function names must be *mangled* to use in
suppressions! No wonder people were having difficulty writing their own
suppressions. The manual only mentioned this under the description of the
--demangle option, which was very easy to miss.
Comments welcome.
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 19:16:14
|
On Tue, 18 Mar 2003, Julian Seward wrote: > cvs diff -rHEAD file.c ? > > Do you have a ~/.cvsrc as below? That might make a difference. > (perhaps the diff -u3 -p is the important bit) > > cvs -z4 -q > diff -u3 -p > update -dP > checkout -P Ok, I thought the lines like this: Index: coregrind/vg_errcontext.c =================================================================== RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_errcontext.c,v retrieving revision 1.29 would screw it up, but it seems to work ok. Thanks. N |
|
From: Jeremy F. <je...@go...> - 2003-03-18 19:02:30
|
On Tue, 2003-03-18 at 04:37, Eyal Lebedinsky wrote:
> '%d' is good for 'int', what is the correct one for 'Int'? If I
> use '%ld' then I violated the type hiding. In C this is a problem
> and for this reason I prefer to use basic types wherever I can, and
> typedef only where actually necessary.
No. VG_(message) is a Valgrind-internal function, so it is defined in
terms of Int, Char, etc, including the interpretation of %d. %ld is for
Long, which is 64 bits.
J
|
|
From: Jeremy F. <je...@go...> - 2003-03-18 19:01:26
|
On Tue, 2003-03-18 at 04:41, Nicholas Nethercote wrote:
> We use '%d' everywhere. I guess the use of Int instead of int isn't so
> important, more a convention maybe (although Julian may disagree).
It took me a while to work out that "Long" is not the same as "long".
Its a bit of a trap.
J
|
|
From: Julian S. <js...@ac...> - 2003-03-18 18:43:52
|
cvs diff -rHEAD file.c ? Do you have a ~/.cvsrc as below? That might make a difference. (perhaps the diff -u3 -p is the important bit) J cvs -z4 -q diff -u3 -p update -dP checkout -P On Tuesday 18 March 2003 12:20 pm, Nicholas Nethercote wrote: > Hi, > > Stupid question time: how do I generate a patch containing the > differences between my workspace and the CVS HEAD, which can be used with > 'patch' by others? > > I want to send a patch to the list for the automatic suppression > generation feature I just hacked up, but I'm not sure of the arguments to > "cvs diff"... my diffs don't look like the ones other people have posted. > > Thanks. > > N > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Does your code think in ink? > You could win a Tablet PC. Get a free Tablet PC hat just for playing. > What are you waiting for? > http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Eyal L. <ey...@ey...> - 2003-03-18 12:52:27
|
I spent the last week trying to speed up valgrind for my heavily multithreaded system. My approach was very simplistic, just reducing the nanosleeps. I found that dropping all the hardcoded times of the form 'nn * 1000 * 1000' to '1 * 1000 * 1000' reduced the real time by a factor of 2.5 (from over 17h to under 7h). Reducing the time further has no effect, until at some point the process shifts from idle wait to busy wait (98% idle -> 0% idle) but the real time stays the same. Reducing it further will then cause the process to take far more time that originally. I still do not understand how the job runs with a 98% idle time, and must assume that better mt implementation has the potential for much more improvement. Without vg the system uses the CPU 100% and I expected vg to be even more CPU heavy. I tested this on a 1200 Athlon and 2800 P4 (both UP). BTW, in order to test very short times I had to change the thread scheduling time (awaken_at) from millisecs to microsecs. As it turned out this was not necessary. Finally, it seeems that doing the time reduction only in vg_libpthread.c is enough, the other few cases do not affect this issue much. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 12:42:05
|
> And when hiding types, how do I do this: > VG_(message)(Vg_UserMsg, "Time: %d/%02d/%02d %02d:%02d:%02d", > tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday, > tm.tm_hour, tm.tm_min, tm.tm_sec ); > > '%d' is good for 'int', what is the correct one for 'Int'? If I > use '%ld' then I violated the type hiding. In C this is a problem > and for this reason I prefer to use basic types wherever I can, and > typedef only where actually necessary. We use '%d' everywhere. I guess the use of Int instead of int isn't so important, more a convention maybe (although Julian may disagree). N |
|
From: Eyal L. <ey...@ey...> - 2003-03-18 12:40:12
|
building from CVS I see that Makefile.am wants version 1.5. I am on Linux Debian Stable, which has 1.4. I built with it and all looked just fine. Is 1.5 really needed? If not, can we please downgrade to 1.4? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Eyal L. <ey...@ey...> - 2003-03-18 12:37:43
|
Nicholas Nethercote wrote:
>
> On Tue, 18 Mar 2003, Eyal Lebedinsky wrote:
>
> > I hope it complies with the current programming model and style (please
> > let me know where it fails to do so).
>
> >From a quick glance, style looks ok. One thing: you use the "long" type
> for VG_(clo_time_zone)... use the Valgrind synonyms (eg. Long, although I
> think UInt would be ok here?)
No, the timezone can be negative, so Int is probably what we want. I can
do this change [attached].
And when hiding types, how do I do this:
VG_(message)(Vg_UserMsg, "Time: %d/%02d/%02d %02d:%02d:%02d",
tm.tm_year+1900, tm.tm_mon+1, tm.tm_mday,
tm.tm_hour, tm.tm_min, tm.tm_sec );
'%d' is good for 'int', what is the correct one for 'Int'? If I
use '%ld' then I violated the type hiding. In C this is a problem
and for this reason I prefer to use basic types wherever I can, and
typedef only where actually necessary.
--
Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 12:29:37
|
On Tue, 18 Mar 2003, Eyal Lebedinsky wrote: > > We should probably #define the built types "int", etc, to some rubbish so > > that any use of them is detected... > > I am not clear on why we want to #define the 'int' types (you mean > inside struct vg_tm, right?). Sorry, I wasn't clear. We want to avoid using "int", "char", "unsigned int", etc, anywhere in the core or in skins, and instead use "Int", "Char", "UInt", etc. (This isn't really critical, I think, more for consistency.) One way to ensure this would be to put something like this in include/vg_skin.h: #define int no_such_type_as_int_use_Int_instead #define char no_such_type_as_char_use_Char_instead Then any accidental use of "int", "char", etc. would cause a compile error. > The added functions do use new types. Mostly, yes; but VG_(clo_time_zone) is a "long". I think it could/should be a "UInt" (32 bits is enough, right?) N |
|
From: Eyal L. <ey...@ey...> - 2003-03-18 12:23:20
|
Nicholas Nethercote wrote: > > On Tue, 18 Mar 2003, Eyal Lebedinsky wrote: > > > I hope it complies with the current programming model and style (please > > let me know where it fails to do so). > > >From a quick glance, style looks ok. One thing: you use the "long" type > for VG_(clo_time_zone)... use the Valgrind synonyms (eg. Long, although I > think UInt would be ok here?) > > We should probably #define the built types "int", etc, to some rubbish so > that any use of them is detected... I am not clear on why we want to #define the 'int' types (you mean inside struct vg_tm, right?). The added functions do use new types. Maybe, if it looks close enough, you can adjust it and check it in, and I will then read it and figure what it is that you wanted. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 12:20:26
|
Hi, Stupid question time: how do I generate a patch containing the differences between my workspace and the CVS HEAD, which can be used with 'patch' by others? I want to send a patch to the list for the automatic suppression generation feature I just hacked up, but I'm not sure of the arguments to "cvs diff"... my diffs don't look like the ones other people have posted. Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 11:34:04
|
On Tue, 18 Mar 2003, Eyal Lebedinsky wrote: > I hope it complies with the current programming model and style (please > let me know where it fails to do so). From a quick glance, style looks ok. One thing: you use the "long" type for VG_(clo_time_zone)... use the Valgrind synonyms (eg. Long, although I think UInt would be ok here?) We should probably #define the built types "int", etc, to some rubbish so that any use of them is detected... > BTW, where is the CVS tree (is it public?). Publicly readable, on Sourceforge: sourceforge.net/cvs/?group_id=46268 N |
|
From: Eyal L. <ey...@ey...> - 2003-03-18 11:16:23
|
Julian Seward wrote: > > Eyal > > It looks like a good patch, and a useful thing too. I would merge > it in, except there is one critical problem which needs fixing first. As promised, here is a clean patch for the new --time-stamp option. I rewrote the logic so it is much simpler. Two general purpose functions were added VG_(time) as the standard time(), but uses type 'vg_time_t' VG_(localtime) as the standard localtime(), but uses type 'vg_tm'. Also, it always sets tm_isdst to zero and timezone is set through clo. I hope it complies with the current programming model and style (please let me know where it fails to do so). BTW, where is the CVS tree (is it public?). -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 09:27:18
|
Hi,
I just discovered a minor bug with --attach-gdb. If an error is caused by
a bad argument to write(), when Valgrind prompts the user whether to drop
into GDB, the first character of the write() is used as the prompt's
input. This program:
int main(void)
{
char buf[5];
buf[0] =3D 'a'; // not one of [yYnNcC]
write(1, buf, 5);
return 0;
}
gives this result:
[njn25@trent head4] vghead4 --gdb-attach=3Dyes a.out
=3D=3D3113=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for x86=
-linux.
=3D=3D3113=3D=3D Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
=3D=3D3113=3D=3D Using valgrind-1.9.4, a program instrumentation system for=
x86-linux.
=3D=3D3113=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
=3D=3D3113=3D=3D Estimated CPU clock rate is 1410 MHz
=3D=3D3113=3D=3D For more details, rerun with: -v
=3D=3D3113=3D=3D
=3D=3D3113=3D=3D Syscall param write(buf) contains uninitialised or unaddre=
ssable byte(s)
=3D=3D3113=3D=3D at 0x402F27B4: __libc_write (in /lib/libc-2.2.4.so)
=3D=3D3113=3D=3D by 0x40235335: __libc_start_main (../sysdeps/generic/li=
bc-start.c:129)
=3D=3D3113=3D=3D by 0x8048330: (within /local/scratch-2/njn25/local/src/=
grind/head4/a.out)
=3D=3D3113=3D=3D Address 0xBFFFF301 is on thread 1's stack
=3D=3D3113=3D=3D
=3D=3D3113=3D=3D ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- a
"@=B0=3D=3D311=
3=3D=3D
=3D=3D3113=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 fro=
m 0)
=3D=3D3113=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D3113=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D3113=3D=3D For a detailed leak analysis, rerun with: --leak-check=3D=
yes
=3D=3D3113=3D=3D For counts of detected errors, rerun with: -v
The `a"@=B0' is the last 4 bytes of the string.
It's a pretty obscure bug, and I don't know how to fix it because it goes
beyond my understanding of how the scheduler works. So maybe it's not
worth fixing. But I thought I'd report it.
N
|