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: Nicholas N. <nj...@ca...> - 2003-03-24 13:19:32
|
On Mon, 24 Mar 2003, Josef Weidendorfer wrote: > > Hmm, one problem is that it requires glibc to not be stripped, since > > spotting function entries relies on symbol information being present. > > I'm not sure whether this is likely or not. > > Symbol information for exported symbols in shared libraries can't be stripped, > as the runtime linker has to know about it. This isn't debug information, and > thus no problem. Ah, good, so no problem there. > I still think that wrapping malloc() is a skin issue, and the core only should > provide convenience functions for doing this in a simply way... I agree. N |
|
From: Josef W. <Jos...@gm...> - 2003-03-24 13:10:17
|
On Sunday 23 March 2003 16:57, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Nicholas Nethercote wrote: > > > An alternative solution for function wrapping would be not to use the > > > runtime linker (symbol overwriding, hack with __libc_malloc), but to > > > change instrumentation of the first BB of the given function, and do a > > > "jmp" into the valgrind wrapper version if the skin would like to use > > > it. > > > > Hey, good idea. I'll have to think about that some more... > > Hmm, one problem is that it requires glibc to not be stripped, since > spotting function entries relies on symbol information being present. > I'm not sure whether this is likely or not. Symbol information for exported symbols in shared libraries can't be stripped, as the runtime linker has to know about it. This isn't debug information, and thus no problem. Static linking with glibc is another issue - but valgrind doesn't work with static binaries at all. > Also, there's the issue of whether malloc() gets called before Valgrind > gains control, possibly because of static C++ constructors. I've > discussed this with Julian before but I cannot remember what the outcome > was, so maybe I'm wrong. Hmm. malloc() is passing requests to arena_malloc() if not running on the simulated CPU. I still think that wrapping malloc() is a skin issue, and the core only should provide convenience functions for doing this in a simply way... Josef |
|
From: Josef W. <Jos...@gm...> - 2003-03-24 13:10:16
|
On Sunday 23 March 2003 17:03, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > > In my latest calltree version, I introduced an infrastruction to specify > > instrumentation parameters on the basis of a function symbol name. > > [snip] > > Does it make sense to merge this in some way with the error suppression > > stuff? > > By this, I'm guessing you mean: after reading suppressions, if Valgrind > translates a function that is mentioned in a suppression, don't instrument > it because any errors from it will be suppressed anyway? No, I didn't thought about any concrete use cases for other skins. It's more about generalizing the idea of suppressions. I think I first have to work it out in my skin and perhaps propose a patch for the core later on. > Two problems with that: (a, minor) you don't get counts of the number of > errors suppressed, and (b, major) suppressions rely on calling context, so Oh. I have to look at the suppression code more deeply :-) Josef > just considering a function by itself wouldn't work -- errors from it > might need to be suppressed if called from function f(), but not if called > from function g(). > > Or maybe I misinterpreted your question... > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@ca...> - 2003-03-23 16:03:26
|
On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > In my latest calltree version, I introduced an infrastruction to specify > instrumentation parameters on the basis of a function symbol name. > [snip] > Does it make sense to merge this in some way with the error suppression stuff? By this, I'm guessing you mean: after reading suppressions, if Valgrind translates a function that is mentioned in a suppression, don't instrument it because any errors from it will be suppressed anyway? Two problems with that: (a, minor) you don't get counts of the number of errors suppressed, and (b, major) suppressions rely on calling context, so just considering a function by itself wouldn't work -- errors from it might need to be suppressed if called from function f(), but not if called from function g(). Or maybe I misinterpreted your question... N |
|
From: Nicholas N. <nj...@ca...> - 2003-03-23 15:57:29
|
On Fri, 21 Mar 2003, Nicholas Nethercote wrote: > > An alternative solution for function wrapping would be not to use the runtime > > linker (symbol overwriding, hack with __libc_malloc), but to change > > instrumentation of the first BB of the given function, and do a "jmp" into > > the valgrind wrapper version if the skin would like to use it. > > Hey, good idea. I'll have to think about that some more... Hmm, one problem is that it requires glibc to not be stripped, since spotting function entries relies on symbol information being present. I'm not sure whether this is likely or not. Also, there's the issue of whether malloc() gets called before Valgrind gains control, possibly because of static C++ constructors. I've discussed this with Julian before but I cannot remember what the outcome was, so maybe I'm wrong. N |
|
From: Julian S. <js...@ac...> - 2003-03-21 19:23:54
|
On Tuesday 18 March 2003 12:40 pm, Eyal Lebedinsky wrote: > 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? Um, influential people are pushing in the opposite direction, suggesting that 1.6 is the minimum that should be supported, and I have to say that sounds better in the long(er) term. J |
|
From: Josef W. <Jos...@gm...> - 2003-03-21 16:47:41
|
On Friday 21 March 2003 17:15, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > > Does it make sense to merge this in some way with the error suppression > > stuff? > > What do you mean by "instrumentation parameters"? Parameters specified by the user at runtime, which influence the instrumentation added to the basic block(s) of a function. E.g. I support command line options "--fn-recursion<no>=<function>", "--dump-before=<function>", "--fn-skip=<function>", allowing to specify an option multiple times for different functions. When entering a function the first time in a program run, the instrumentation is done. Above parameters can influence the instrumentation of the BB. OK, perhaps it's not the right word, as often only the behaviour of some helper function is changed, called by the instrumentation done. Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-03-21 16:28:17
|
On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > Doesn't GCC use it's own inline-version of memcpy when optimization is on? Yes. Not much you can do; the user manual recommends turning off optimisation anyway ;) (Actually, I think it compromises on -O...) > An alternative solution for function wrapping would be not to use the runtime > linker (symbol overwriding, hack with __libc_malloc), but to change > instrumentation of the first BB of the given function, and do a "jmp" into > the valgrind wrapper version if the skin would like to use it. Hey, good idea. I'll have to think about that some more... > In my latest calltree version, I introduced an infrastruction to specify > instrumentation parameters on the basis of a function symbol name. > This would be a good addition to valgrind core, and would come handy > with the above wrapping (wrapper function as parameter dependent on symbol > name). > [...] > Does it make sense to merge this in some way with the error suppression stuff? What do you mean by "instrumentation parameters"? N |
|
From: Josef W. <Jos...@gm...> - 2003-03-21 15:40:52
|
On Friday 21 March 2003 10:42, Nicholas Nethercote wrote:
> I've been thinking about Josef's suggestion about letting the skin decide
> if it wants to use __libc_malloc() or Valgrind's malloc(), and whether to
> wrap them. I think it could be done, although I haven't got around to
> trying it yet. This {mem,str,strn}cpy() checking could be done
> similarly... Memcheck and Addrcheck would use Valgrind's provided
> versions, using a wrapper that checks the args don't overlap, and other
> skins could use the libc versions. Ah, except it seems that glibc doesn't
> define __libc_memcpy the way it does __libc_malloc, which could make
> things tricky.
Hmm...
Doesn't GCC use it's own inline-version of memcpy when optimization is on?
An alternative solution for function wrapping would be not to use the runtime
linker (symbol overwriding, hack with __libc_malloc), but to change
instrumentation of the first BB of the given function, and do a "jmp" into
the valgrind wrapper version if the skin would like to use it.
This avoids the static behaviour of symbol definitions in shared libraries,
and can even be done by valgrind core before calling the instrumentation
function of the skin. Still, in the case of wrapping, the instrumentation
function of the skin should get the replaced jump for further
instrumentation.
> Still, this whole question of "do I use the normal version or Valgrind's
> version of function x()" is worth investigation, and I hope to look into
> it more soon.
In my latest calltree version, I introduced an infrastruction to specify
instrumentation parameters on the basis of a function symbol name.
This would be a good addition to valgrind core, and would come handy
with the above wrapping (wrapper function as parameter dependent on symbol
name).
As the lookup for instrumentation parameters has to be done on instrumentation
of every basic block, this has to be fast. I use a prefix tree for lookup.
This even allows to only specify symbol prefixes, i.e. a star wildcard at the
end.
E.g. say you have set
- parameter A=0 for symbol "foo1",
- parameter A=1 for symbol "foo1bar",
- parameter A=2 for symbol "foo2",
- parameter A=3 for symbol "foo*".
The prefix search tree looks like this:
"foo"
+-- "*": A=3
+-- "1": A=0
+-- "bar": A=1
+-- "2": A=2
e.g. if you have symbol "foobar", it goes down the tree and stops with A=3.
Does it make sense to merge this in some way with the error suppression stuff?
Josef
PS: Nick, could you send me the scripts for the SPEC2000 benchmarks?
I would like to check it with my skin.
>
> N
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-21 10:08:24
|
Hi,
I've been doing some benchmarking, I thought I'd report the results since
AFAIK nobody has done tests this thorough before.
All experiments were performed on an AMD Athlon 1400 MHz with 1GB of RAM
(recent upgrade from 256MB :) running Red Hat Linux 7.1, kernel version
2.4.19. The test programs are a subset of the SPEC2000 suite, basically
those ones I could get to work. All were tested with the ``test''
(smallest) inputs. I didn't test Helgrind because the programs aren't
threaded, so it would have been a bit pointless.
First of all was time performance.
Program Time Nulgrind Memcheck Addrcheck Cachegrind
------------------------------------------------------
bzip2 10.8s 2.5 14.1 10.0 30.9
crafty 3.2s 7.5 55.2 36.5 117.6
gap 0.9s 5.5 35.1 25.9 48.5
gcc 1.5s 8.6 38.9 27.4 70.3
gzip 1.8s 4.4 26.5 20.9 53.3
mcf 0.3s 2.8 12.1 6.3 18.5
parser 3.4s 3.6 21.6 17.0 34.3
twolf 0.2s 5.0 31.1 21.3 50.9
vortex 6.5s 7.7 62.8 52.2 88.1
------------------------------------------------------
ammp 19.3s 2.2 24.1 21.0 46.5
art 26.1s 6.1 14.1 11.4 20.0
equake 2.1s 6.1 30.5 28.3 50.4
mesa 2.7s 4.9 41.5 32.7 63.4
------------------------------------------------------
Column 1 gives the benchmark name, column 2 gives the time taken to run
the benchmark normally, and columns 3--6 gives the slowdown factor for
each skin. Programs above the line are integer programs, those below are
floating point programs.
Second was code expansion.
Program Code size Nulgrind Memcheck Addrcheck Cachegrind
----------------------------------------------------------------
bzip2 32KB 5.1 11.6 6.4 9.1
crafty 153KB 4.4 10.6 5.7 8.1
gap 137KB 5.6 12.4 6.9 9.6
gcc 561KB 5.9 12.8 7.3 9.9
gzip 28KB 5.4 12.1 6.8 9.4
mcf 28KB 5.7 13.0 7.2 9.9
parser 94KB 6.0 13.2 7.4 10.1
twolf 110KB 5.2 11.9 6.7 9.3
vortex 230KB 5.8 12.7 7.6 10.1
----------------------------------------------------------------
ammp 64KB 4.6 11.4 6.8 9.5
art 21KB 5.5 12.5 7.0 9.8
equake 42KB 5.0 11.8 6.7 9.2
mesa 65KB 4.7 10.8 6.4 8.9
----------------------------------------------------------------
Format is the same, except column two shows original code size.
I haven't given averages because (a) I'm never sure which average
(arithmetic, geometric, harmonic, pentatonic, teutonic, moronic, whatever)
to use, and (b) averages encourage people to ignore the actual results.
The most interesting things to me were:
1. Variation in slowdown factor -- the worst slowdown for each skin was
4--6 times worse than the best slowdown.
2. How slow Memcheck is: I was thinking it's 10--20 times slower, but it's
usually worse than that.
3. How slow Addrcheck is: it's certainly not twice as fast as Addrcheck.
Maybe 30% faster.
4. crafty has the worst overall time performance, but the smallest code
expansion. It's a chess puzzle solver that uses 64-bit longs heavily,
which maybe Valgrind doesn't handle so well timewise.
If anyone else who has the SPEC2000 benchmark suite is interested in
running tests on their machine, let me know and I'll send you my test
script and instructions on how to use it.
N
|
|
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 |