You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(9) |
2
(5) |
3
(1) |
4
(4) |
5
|
6
(8) |
7
(12) |
|
8
(6) |
9
(10) |
10
(6) |
11
(8) |
12
(12) |
13
(5) |
14
(1) |
|
15
(1) |
16
(12) |
17
(9) |
18
(4) |
19
(8) |
20
(4) |
21
(1) |
|
22
|
23
(4) |
24
(12) |
25
(13) |
26
(16) |
27
(4) |
28
(2) |
|
29
(1) |
30
(4) |
31
(9) |
|
|
|
|
|
From: Howard C. <hy...@sy...> - 2006-01-26 15:42:14
|
Ashley Pittman wrote: > On Thu, 2006-01-26 at 07:26 +0100, Oswald Buddenhagen wrote: > >> On Wed, Jan 25, 2006 at 06:36:19PM -0800, Graydon Hoare wrote: >> >>> I'm working on characterizing mozilla's memory use, in order to >>> eventually make it use less. I am hoping to use valgrind for this. >>> >>> >> ok, maybe i'm totally wrong, but i would not use valgrind for this. >> as you want to do allocation and leak tracking only, you don't need any >> instrumentation except wrapping the allocator functions (which, i guess, >> the nspr(?) does anyway) and doing a snapshot each time you need it >> (memcheck does the same, afaik). that would mean that integrating a >> *way* more lightweight "classical" memory debugger library would be more >> appropriate. depends on what else you want to track at the same time ... >> > > Sorry if this is too off-topic for this list... > > I've done exactly this to track memory leaks in programs, it's actually > quite easy once you know how. > > There are hooks inside libc (man 3 malloc_hook) you can use to intercept > every malloc/calloc/memalign/free call from everywhere in the > application/library's it's using (you don't even need the source to do > this). These callbacks are given the size and base of the buffer but > also the return address for the function that called malloc() in the > first place. > Those hooks only exist for glibc. My FunctionCheck code shows how to intercept malloc/etc. for any libdl-based dynamic library platform (e.g. Solaris, Irix, Linux, etc...) http://www.highlandsun.com/hyc/#fncchk -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ |
|
From: Ashley P. <as...@qu...> - 2006-01-26 15:26:21
|
On Thu, 2006-01-26 at 07:26 +0100, Oswald Buddenhagen wrote:
> On Wed, Jan 25, 2006 at 06:36:19PM -0800, Graydon Hoare wrote:
> > I'm working on characterizing mozilla's memory use, in order to
> > eventually make it use less. I am hoping to use valgrind for this.
> >
> ok, maybe i'm totally wrong, but i would not use valgrind for this.
> as you want to do allocation and leak tracking only, you don't need any
> instrumentation except wrapping the allocator functions (which, i guess,
> the nspr(?) does anyway) and doing a snapshot each time you need it
> (memcheck does the same, afaik). that would mean that integrating a
> *way* more lightweight "classical" memory debugger library would be more
> appropriate. depends on what else you want to track at the same time ...
Sorry if this is too off-topic for this list...
I've done exactly this to track memory leaks in programs, it's actually
quite easy once you know how.
There are hooks inside libc (man 3 malloc_hook) you can use to intercept
every malloc/calloc/memalign/free call from everywhere in the
application/library's it's using (you don't even need the source to do
this). These callbacks are given the size and base of the buffer but
also the return address for the function that called malloc() in the
first place.
I simply print these out to a file using this format:
Inside malloc:
printf("libc + %zi %p %p\n",size,result,caller);
Inside free:
printf("libc - %p %p\n",start,caller);
I've then got a piece of perl which parses this log file to find buffers
which were allocated but not freed and uses addr2line to convert these
back into source file and line numbers. I'll send on the perl and hooks
if you want them... It doesn't get you full stack traces but it's often
good enough, particularly if you know the source well anyway.
Ashley,
|
|
From: Dallman, J. <jg...@ug...> - 2006-01-26 14:36:01
|
> Do you guys think that if I used wrapmsvc (some wrapper=20 > for msvc to use gcc, translating arguments from msvc to=20 > gnu type), will valgrind work? No. I'm impressed by the degree to which you've misunderstood=20 the issues involved, though. From a quick Google and your=20 comments, wrapmsvc, is a tool for translating gcc compilation=20 options into the corresponding msvc ones, so that one can use=20 msvc with makefiles set up for gcc. Is that right? If so, this=20 about equivalent to teaching someone to swim by putting them=20 into a swimming costume and claiming you've finished.=20 What will matter to Valgrind is what the compiler produces, rather than how you ask the compiler to do things. And=20 Valgrind only understands programs that are built for Linux (and very similar operating systems, when built for them).=20 Windows is a very different operating system indeed, and Valgrind does not understand Windows issues at all. Yes, it would be useful if it did. But it doesn't, and to make it=20 do so would require a great deal of work. Nobody has come=20 along with both the motivation and the skills to do that as yet.=20 To save your time, here are two other things that won't work: * DJPP, or Cygwin, or other toolsets that allow you to run=20 GCC on Windows for producing Windows programs. This is no=20 help because you'd still be asking Valgrind to work on a=20 Windows program, and it doesn't know how to do that.=20 * WINE, or other Windows emulators for Linux. These allow a Windows program to run on Linux, by surrounding it with a semi-complete simulation of Windows. That still wouldn't=20 let Valgrind deal with a Windows program. You could run=20 Valgrind on the Windows emulator, which would include the Windows program running within it, but the odds of ever learning anything useful from this are very small: it's=20 too complicated.=20 --=20 John Dallman, Parasolid Porting Engineer, +44-1223-371554=20 |
|
From: KevinGPO <kev...@ho...> - 2006-01-26 13:40:25
|
Do you guys think that if I used wrapmsvc (some wrapper for msvc to use gcc, translating arguments from msvc to gnu type), will valgrind work? "Jorrit Tyberghein" <jor...@gm...> wrote in message news:d48...@ma...... On 1/25/06, Dennis Lubert <pla...@in...> wrote: > At 13:59 25.01.2006, Christian Parpart wrote: > > > Porting VC++ 6.0 code to linux could be a bigger problem though, > > > since it is known to horribly fail to comply to the iso c++ standard, > > > as an example it does not following scoping rules for for-loops and > > > has differente template syntax. > > > >best time to revalidate the sources and make it compliant though ;-) > But then it doest work with VC++6.0 any more *evil laugther* Actually it is possible to make it work on VC++6.0 AND later. In some cases you have to do some tricks but in CS we have always been compatible with VC6 and higher. Of course now we're dropping VC6 support so we can remove a few of those hacks. Greetings, > > greets > > Dennis > > Carpe quod tibi datum est > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Project Manager of Crystal Space (http://www.crystalspace3d.org) and CEL (http://cel.crystalspace3d.org) Support Crystal Space. Donate at https://sourceforge.net/donate/index.php?group_id=649 ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 |
|
From: Julian S. <js...@ac...> - 2006-01-26 13:37:24
|
> I can send the offending the xml file if needed. Please do. J |
|
From: Cees <ce...@pc...> - 2006-01-26 09:08:58
|
Hi, I am using valgrind-3.1.0-Debian and discovered that the XML output is wrong when it has to report very large function names. A certain C++ function signature is over 3900 char's wrong. For that frame, the XML frame element only has <fn>...very long.. No </fn> and no </frame> I can send the offending the xml file if needed. Regards, Cees |
|
From: Oswald B. <os...@kd...> - 2006-01-26 06:26:37
|
On Wed, Jan 25, 2006 at 06:36:19PM -0800, Graydon Hoare wrote: > I'm working on characterizing mozilla's memory use, in order to > eventually make it use less. I am hoping to use valgrind for this. > ok, maybe i'm totally wrong, but i would not use valgrind for this. as you want to do allocation and leak tracking only, you don't need any instrumentation except wrapping the allocator functions (which, i guess, the nspr(?) does anyway) and doing a snapshot each time you need it (memcheck does the same, afaik). that would mean that integrating a *way* more lightweight "classical" memory debugger library would be more appropriate. depends on what else you want to track at the same time ... -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Julian S. <js...@ac...> - 2006-01-26 04:58:26
|
> I am experiencing the following problem (application being killed) when > trying to use Valgrind's memcheck program. Any ideas as to what might be > the issue? Your program is dying as a result of the errors that Valgrind reports, as it eventually trashes memory belonging to V itself. Track down and fix the *first* error that V reports: > ==15759== Conditional jump or move depends on uninitialised value(s) > ==15759== at 0x4095FB: AddVertex (graphops.c:438) > ==15759== by 0x40EB4F: ReadIncrementVertex (gendata.c:312) > ==15759== by 0x40E8FC: ReadIncrement (gendata.c:247) > ==15759== by 0x40E599: CreateFromFile (gendata.c:142) > ==15759== by 0x40E43A: GetNextIncrement (gendata.c:85) > ==15759== by 0x4014DE: ISubdue (main.c:223) > ==15759== by 0x4010DF: main (main.c:53) Keep doing that until V reports no errors. I bet the program will stay alive after that. J |
|
From: Bill E. <eb...@cs...> - 2006-01-26 04:02:20
|
Dear Valgrind Users, I am experiencing the following problem (application being killed) when = trying to use Valgrind's memcheck program. Any ideas as to what might = be the issue? Thanks, Bill Output from uname -a: 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 x86_64 x86_64 x86_64 = GNU/Linux Log file (with -v on): =3D=3D15759=3D=3D Memcheck, a memory error detector. =3D=3D15759=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D15759=3D=3D Using LibVEX rev 1313, a library for dynamic binary = translation. =3D=3D15759=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks = LLP. =3D=3D15759=3D=3D Using valgrind-3.0.1.SVN, a dynamic binary = instrumentation framework. =3D=3D15759=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian = Seward et al. =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D My PID =3D 15759, parent PID =3D 29110. Prog and args = are: =3D=3D15759=3D=3D valgrind.src/subdue =3D=3D15759=3D=3D -inc =3D=3D15759=3D=3D -eval =3D=3D15759=3D=3D 2 =3D=3D15759=3D=3D -limit =3D=3D15759=3D=3D 225 =3D=3D15759=3D=3D eagle_data/my_30_increments/graph_inc --15759--=20 --15759-- Valgrind library directory: /usr/lib64/valgrind --15759-- Command line --15759-- valgrind.src/subdue --15759-- -inc --15759-- -eval --15759-- 2 --15759-- -limit --15759-- 225 --15759-- eagle_data/my_30_increments/graph_inc --15759-- Startup, with flags: --15759-- --tool=3Dmemcheck --15759-- -v --15759-- --error-limit=3Dno --15759-- --log-file-exactly=3Dvalgrind.log --15759-- Contents of /proc/version: --15759-- Linux version 2.6.13-15-smp (geeko@buildhost) (gcc version = 4.0.2 20050901 (prerelease) (SUSE Linux)) #1 SMP Tue Sep 13 14:56:15 UTC = 2005 --15759-- Reading syms from = /export/home/eberle/subdue/subdue-5.2/valgrind.src/subdue (0x400000) --15759-- Reading syms from /lib64/ld-2.3.5.so (0x11900000) --15759-- Reading suppressions file: /usr/lib64/valgrind/default.supp =3D=3D15759=3D=3D=20 --15759-- Reading syms from /usr/lib64/valgrind/vg_preload_core.so = (0x11A18000) --15759-- object doesn't have a symbol table --15759-- Reading syms from /usr/lib64/valgrind/vgpreload_memcheck.so = (0x11B19000) --15759-- object doesn't have a symbol table --15759-- REDIR: 0x1190EE60 (index) redirected to 0x11B1C990 (index) --15759-- REDIR: 0x1190F010 (strcmp) redirected to 0x11B1CB20 (strcmp) --15759-- REDIR: 0x1190F350 (strlen) redirected to 0x11B1CA30 (strlen) --15759-- Reading syms from /lib64/tls/libm-2.3.5.so (0x11C58000) --15759-- Reading syms from /lib64/tls/libc-2.3.5.so (0x11DAF000) --15759-- Reading syms from /lib64/libdl-2.3.5.so (0x11FDA000) --15759-- REDIR: 0x11E1A730 (calloc) redirected to 0x11B1C180 (calloc) --15759-- REDIR: 0x11E220C0 (memcpy) redirected to 0x11B1CDF0 (memcpy) --15759-- REDIR: 0x11E1FFC0 (rindex) redirected to 0x11B1C840 (rindex) --15759-- REDIR: 0x11E1F5C0 (strlen) redirected to 0x11B1C9F0 (strlen) --15759-- REDIR: 0x11E1AA80 (malloc) redirected to 0x11B1AE1D (malloc) --15759-- REDIR: 0x11E22D90 (rawmemchr) redirected to 0x11B1CDD0 = (rawmemchr) --15759-- REDIR: 0x11E1EB80 (strcpy) redirected to 0x11B1D030 (strcpy) --15759-- REDIR: 0xFFFFFFFFFF600400 (???) redirected to 0x70029935 (???) --15759-- REDIR: 0x11E1E4B0 (strcat) redirected to 0x11B1CF60 (strcat) --15759-- REDIR: 0x11E1B0C0 (realloc) redirected to 0x11B1C229 (realloc) =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x4095FB: AddVertex (graphops.c:438) =3D=3D15759=3D=3D by 0x40EB4F: ReadIncrementVertex (gendata.c:312) =3D=3D15759=3D=3D by 0x40E8FC: ReadIncrement (gendata.c:247) =3D=3D15759=3D=3D by 0x40E599: CreateFromFile (gendata.c:142) =3D=3D15759=3D=3D by 0x40E43A: GetNextIncrement (gendata.c:85) =3D=3D15759=3D=3D by 0x4014DE: ISubdue (main.c:223) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) --15759-- REDIR: 0x11E1E820 (strcmp) redirected to 0x11B1CAD0 (strcmp) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x4097B6: AddEdge (graphops.c:541) =3D=3D15759=3D=3D by 0x40EC6E: ReadIncrementEdge (gendata.c:370) =3D=3D15759=3D=3D by 0x40E952: ReadIncrement (gendata.c:251) =3D=3D15759=3D=3D by 0x40E599: CreateFromFile (gendata.c:142) =3D=3D15759=3D=3D by 0x40E43A: GetNextIncrement (gendata.c:85) =3D=3D15759=3D=3D by 0x4014DE: ISubdue (main.c:223) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x11B1C272: realloc (in = /usr/lib64/valgrind/vgpreload_memcheck.so) =3D=3D15759=3D=3D by 0x4097CB: AddEdge (graphops.c:544) =3D=3D15759=3D=3D by 0x40EC6E: ReadIncrementEdge (gendata.c:370) =3D=3D15759=3D=3D by 0x40E952: ReadIncrement (gendata.c:251) =3D=3D15759=3D=3D by 0x40E599: CreateFromFile (gendata.c:142) =3D=3D15759=3D=3D by 0x40E43A: GetNextIncrement (gendata.c:85) =3D=3D15759=3D=3D by 0x4014DE: ISubdue (main.c:223) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) --15759-- REDIR: 0x11E18E30 (free) redirected to 0x11B1B9B5 (free) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x406C73: AddPosInstancesToSub (extend.c:337) =3D=3D15759=3D=3D by 0x406680: ExtendSub (extend.c:63) =3D=3D15759=3D=3D by 0x404981: DiscoverSubs (discover.c:78) =3D=3D15759=3D=3D by 0x401601: ISubdue (main.c:263) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x406645: ExtendSub (extend.c:55) =3D=3D15759=3D=3D by 0x404981: DiscoverSubs (discover.c:78) =3D=3D15759=3D=3D by 0x401601: ISubdue (main.c:263) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x406647: ExtendSub (extend.c:55) =3D=3D15759=3D=3D by 0x404981: DiscoverSubs (discover.c:78) =3D=3D15759=3D=3D by 0x401601: ISubdue (main.c:263) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Invalid read of size 8 =3D=3D15759=3D=3D at 0x40C477: NewEdgeMatch (subops.c:1375) =3D=3D15759=3D=3D by 0x406C60: AddPosInstancesToSub (extend.c:333) =3D=3D15759=3D=3D by 0x406680: ExtendSub (extend.c:63) =3D=3D15759=3D=3D by 0x404981: DiscoverSubs (discover.c:78) =3D=3D15759=3D=3D by 0x401601: ISubdue (main.c:263) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D Address 0x1234CE00 is not stack'd, malloc'd or = (recently) free'd =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Invalid read of size 8 =3D=3D15759=3D=3D at 0x40C47B: NewEdgeMatch (subops.c:1375) =3D=3D15759=3D=3D by 0x406C60: AddPosInstancesToSub (extend.c:333) =3D=3D15759=3D=3D by 0x406680: ExtendSub (extend.c:63) =3D=3D15759=3D=3D by 0x404981: DiscoverSubs (discover.c:78) =3D=3D15759=3D=3D by 0x401601: ISubdue (main.c:263) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D Address 0x12317DC0 is not stack'd, malloc'd or = (recently) free'd =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x40690F: CreateExtendedInstance (extend.c:195) =3D=3D15759=3D=3D by 0x40F2E9: FindInitialBoundaryInstances = (incboundary.c:438) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x406926: CreateExtendedInstance (extend.c:197) =3D=3D15759=3D=3D by 0x40F2E9: FindInitialBoundaryInstances = (incboundary.c:438) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x40698B: CreateExtendedInstance (extend.c:211) =3D=3D15759=3D=3D by 0x40F2E9: FindInitialBoundaryInstances = (incboundary.c:438) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x4069A2: CreateExtendedInstance (extend.c:213) =3D=3D15759=3D=3D by 0x40F2E9: FindInitialBoundaryInstances = (incboundary.c:438) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x40690F: CreateExtendedInstance (extend.c:195) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F334: FindInitialBoundaryInstances = (incboundary.c:450) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x406926: CreateExtendedInstance (extend.c:197) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F334: FindInitialBoundaryInstances = (incboundary.c:450) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x40698B: CreateExtendedInstance (extend.c:211) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F334: FindInitialBoundaryInstances = (incboundary.c:450) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x4069A2: CreateExtendedInstance (extend.c:213) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F334: FindInitialBoundaryInstances = (incboundary.c:450) =3D=3D15759=3D=3D by 0x40ECE0: EvaluateBoundaryInstances = (incboundary.c:41) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x40690F: CreateExtendedInstance (extend.c:195) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F679: ProcessExtendedInstances = (incboundary.c:693) =3D=3D15759=3D=3D by 0x40F530: ExtendBoundaryInstances = (incboundary.c:580) =3D=3D15759=3D=3D by 0x40F0A2: ProcessInstancesForSub = (incboundary.c:277) =3D=3D15759=3D=3D by 0x40EDEB: EvaluateBoundaryInstances = (incboundary.c:97) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x406926: CreateExtendedInstance (extend.c:197) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F679: ProcessExtendedInstances = (incboundary.c:693) =3D=3D15759=3D=3D by 0x40F530: ExtendBoundaryInstances = (incboundary.c:580) =3D=3D15759=3D=3D by 0x40F0A2: ProcessInstancesForSub = (incboundary.c:277) =3D=3D15759=3D=3D by 0x40EDEB: EvaluateBoundaryInstances = (incboundary.c:97) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x40698B: CreateExtendedInstance (extend.c:211) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F679: ProcessExtendedInstances = (incboundary.c:693) =3D=3D15759=3D=3D by 0x40F530: ExtendBoundaryInstances = (incboundary.c:580) =3D=3D15759=3D=3D by 0x40F0A2: ProcessInstancesForSub = (incboundary.c:277) =3D=3D15759=3D=3D by 0x40EDEB: EvaluateBoundaryInstances = (incboundary.c:97) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) =3D=3D15759=3D=3D=20 =3D=3D15759=3D=3D Conditional jump or move depends on uninitialised = value(s) =3D=3D15759=3D=3D at 0x4069A2: CreateExtendedInstance (extend.c:213) =3D=3D15759=3D=3D by 0x40ABB2: ExtendInstancesByEdge (sgiso.c:191) =3D=3D15759=3D=3D by 0x40FC3D: CheckForSubgraph (incboundary.c:1017) =3D=3D15759=3D=3D by 0x40F679: ProcessExtendedInstances = (incboundary.c:693) =3D=3D15759=3D=3D by 0x40F530: ExtendBoundaryInstances = (incboundary.c:580) =3D=3D15759=3D=3D by 0x40F0A2: ProcessInstancesForSub = (incboundary.c:277) =3D=3D15759=3D=3D by 0x40EDEB: EvaluateBoundaryInstances = (incboundary.c:97) =3D=3D15759=3D=3D by 0x4016DA: ISubdue (main.c:305) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) --15759-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - = exiting --15759-- si_code=3D1; Faulting address: 0x0; sp: 0x70156E90 valgrind: the 'impossible' happened: Killed by fatal signal =3D=3D15759=3D=3D at 0x2AAAAAF1B3F7: ??? sched status: running_tid=3D1 Thread 1: status =3D VgTs_Runnable =3D=3D15759=3D=3D at 0x11B1C2F2: realloc (in = /usr/lib64/valgrind/vgpreload_memcheck.so) =3D=3D15759=3D=3D by 0x409618: AddVertex (graphops.c:441) =3D=3D15759=3D=3D by 0x40EB4F: ReadIncrementVertex (gendata.c:312) =3D=3D15759=3D=3D by 0x40E8FC: ReadIncrement (gendata.c:247) =3D=3D15759=3D=3D by 0x40E599: CreateFromFile (gendata.c:142) =3D=3D15759=3D=3D by 0x40E43A: GetNextIncrement (gendata.c:85) =3D=3D15759=3D=3D by 0x4014DE: ISubdue (main.c:223) =3D=3D15759=3D=3D by 0x4010DF: main (main.c:53) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. |
|
From: Graydon H. <gr...@po...> - 2006-01-26 03:00:42
|
Hi, I'm working on characterizing mozilla's memory use, in order to eventually make it use less. I am hoping to use valgrind for this. To do this I am hoping to add a small mozilla component to our debugging builds, such that when it runs under valgrind the component can make memcheck client requests to measure the reachable and leaking portions of the heap. I see that memcheck already has some client requests for this purpose, and I see that the manual suggests that the VALGRIND_DO_LEAK_CHECK request "could be used to incrementally check for leaks between arbitrary places in the program's execution". This comment fills me with hope. I wonder if I could ask some advice on using this request, and/or extending the request to slightly new behavior. What I want to do is employ a *pair* of requests, a "punch-in" and a "punch-out" request, such that the *differences* in both the reachable and leaked sets, between punch-in and punch-out, can be reported. The use case I envision is that "debugging users" can press a button in their "debugging browser" to "start recording", then execute some actions which should ideally free all the memory they allocate (say, open a tab to a particular page, browse around, and close the tab), and then press the button again to reveal how much memory leaked *and* how much new reachable memory was allocated in the heap (cycles, accidentally-held references, etc). For all such memory allocated in the "recording window" -- leaks and otherwise -- I will of course want to retrieve allocation call stacks. I believe that *most* of the machinery for this task is present already in memcheck. I wonder if anyone has any advice about how to "finish the job", and make this functionality real. I'm happy to do all the work myself, but I figure some valgrind old hands might be able to reply with a helpful suggestion or two which might save me a few weeks of dead-ends while tying it all together. Thanks, -graydon |
|
From: Nicholas N. <nj...@cs...> - 2006-01-26 02:52:21
|
On Wed, 25 Jan 2006, Julian Seward wrote: >> One problem is that Valgrind's client requests currently have a maximum of >> four arguments. > > Pretty harmless. All the args are passed in a block in memory to > avoid getting tangled in an args-in-registers style swamp, so > that block can easily be expanded by one word to accommodate an > extra argument. But then VALGRIND_MAGIC_SEQUENCE would have 8 args instead of 7, which would screw up things for those existing uses of it in people's code, no? Nick |
|
From: Julian S. <js...@ac...> - 2006-01-25 22:45:42
|
> One problem is that Valgrind's client requests currently have a maximum of > four arguments. Pretty harmless. All the args are passed in a block in memory to avoid getting tangled in an args-in-registers style swamp, so that block can easily be expanded by one word to accommodate an extra argument. J |
|
From: Nicholas N. <nj...@cs...> - 2006-01-25 22:15:24
|
On Wed, 25 Jan 2006, Joe Mason wrote: > The easiest modification to valgrind would be to reinstate GET_VBITS and > SET_VBITS, I guess. Or I could add VALGRIND_REALLOCLIKE_BLOCK(oldaddr, > newaddr, newsize, rz, is_zeroed), where is_zeroed applies only to any > newly allocated memory. Or VALGRIND_RESIZE_MALLOCLIKE_BLOCK(addr, > newsize, rz, is_zeroed), which would only change the size of a malloc'd > block (so only useful for the in-place case). GET_VBITS/SET_VBITS is > most general, but RESIZE_MALLOCLIKE_BLOCK directly attacks the > shortcoming, which is that once a block is MALLOC'd it can't be changed > without discarding the vbits. And REALLOCLIKE_BLOCK preserves the > symmetry of providing hooks for the 3 standard malloc operations. GET_VBITS and SET_VBITS have been reinstated in the COMPVBITS branch, and will be present in 3.2.0, which will probably be out in a couple of months. However, having REALLOCLIKE_BLOCK as well would be good, because it could apply to any tool, whereas GET_VBITS/SET_VBITS are Memcheck-specific. One problem is that Valgrind's client requests currently have a maximum of four arguments. Perhaps the 'rz' parameter could be not used, and we could assume the redzone is the same size as in the original block. Nick |
|
From: Jorrit T. <jor...@gm...> - 2006-01-25 18:10:02
|
On 1/25/06, Dennis Lubert <pla...@in...> wrote: > At 13:59 25.01.2006, Christian Parpart wrote: > > > Porting VC++ 6.0 code to linux could be a bigger problem though, > > > since it is known to horribly fail to comply to the iso c++ standard, > > > as an example it does not following scoping rules for for-loops and > > > has differente template syntax. > > > >best time to revalidate the sources and make it compliant though ;-) > But then it doest work with VC++6.0 any more *evil laugther* Actually it is possible to make it work on VC++6.0 AND later. In some cases you have to do some tricks but in CS we have always been compatible with VC6 and higher. Of course now we're dropping VC6 support so we can remove a few of those hacks. Greetings, > > greets > > Dennis > > Carpe quod tibi datum est > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat= =3D121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Project Manager of Crystal Space (http://www.crystalspace3d.org) and CEL (http://cel.crystalspace3d.org) Support Crystal Space. Donate at https://sourceforge.net/donate/index.php?group_id=3D649 |
|
From: Dennis L. <pla...@in...> - 2006-01-25 17:59:45
|
At 13:59 25.01.2006, Christian Parpart wrote: > > Porting VC++ 6.0 code to linux could be a bigger problem though, > > since it is known to horribly fail to comply to the iso c++ standard, > > as an example it does not following scoping rules for for-loops and > > has differente template syntax. > >best time to revalidate the sources and make it compliant though ;-) But then it doest work with VC++6.0 any more *evil laugther* greets Dennis Carpe quod tibi datum est |
|
From: Joe M. <jo...@no...> - 2006-01-25 17:41:39
|
I'm implemented in a custom memory manager that has semantics like
malloc, free and realloc. malloc and free are easy to integrate with
valgrind using VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK,
but I'm having some problems with realloc.
There are three cases:
1. Can't realloc in place - need to alloc new memory, copy the old chunk
to the new, and free the old chunk.
- Easy: just call VALGRIND_MALLOCLIKE_BLOCK after creating the new
chunk, then valgrind will notices the memcpy and update its vbits
accordingly, then call VALGRIND_FREELIKE_BLOCK on the old chunk.
2. Able to grow allocation in place - need to mark new area addressable.
- It's tempting to just use VALGRIND_MAKE_WRITABLE to mark the new area
as allocated, but of course then valgrind doesn't have the right size
for the malloc'd chunk: attempts to write past the end of the new
memory get the wrong error message ("Address 0x401F200 is not stack'd,
malloc'd or (recently) free'd" instead of "Address 0x401F200 is 0
bytes after a block of size 128 alloc'd"), and calling
VALGRIND_FREELIKE_BLOCK later will only mark the chunk unaddressable
up to its original size.
3. Able to shrink allocation - need to mark part of old area
unaddressable.
- Again, could just use VALGRIND_MAKE_NOACCESS, but then it wouldn't
correctly track the size of the malloc'd chunk.
The only other option I can see for the two in-place cases is to call
VALGRIND_FREELIKE_BLOCK(ptr); VALGRIND_MALLOCLIKE_BLOCK(ptr, newsize) -
but that throws away all the vbits for the area. I could follow it with
VALGRIND_MAKE_READABLE(ptr, max(oldsize, newsize)), but of course
that assumes that the original chunk was entirely in use.
The obvious thing to do is use VALGRIND_GET_VBITS to save the vbits
before the reallocation, and follow it up with VALGRIND_PUT_VBITS
(truncating the array if necessary). Except I see those two calls were
deprecated last year, and aren't even included valgrind-3.1.0-Debian.
So what are my options? Right now, if compiled in debug mode, I'm
adding an extra memcpy for in-place reallocs (copy the memory to a
holding area, realloc in place, then copy it all back) solely so that
valgrind will notice the copy and keep the vbits up to date, but that's
a horrible solution. Is there anything else I could do without
modifying valgrind? (I took a look at MAC_(realloc), but of course it
uses a lot of internal machinery that's not exposed to users.)
The easiest modification to valgrind would be to reinstate GET_VBITS and
SET_VBITS, I guess. Or I could add VALGRIND_REALLOCLIKE_BLOCK(oldaddr,
newaddr, newsize, rz, is_zeroed), where is_zeroed applies only to any
newly allocated memory. Or VALGRIND_RESIZE_MALLOCLIKE_BLOCK(addr,
newsize, rz, is_zeroed), which would only change the size of a malloc'd
block (so only useful for the in-place case). GET_VBITS/SET_VBITS is
most general, but RESIZE_MALLOCLIKE_BLOCK directly attacks the
shortcoming, which is that once a block is MALLOC'd it can't be changed
without discarding the vbits. And REALLOCLIKE_BLOCK preserves the
symmetry of providing hooks for the 3 standard malloc operations.
Any preferences?
Joe
|
|
From: Benjamin C. <ben...@si...> - 2006-01-25 17:31:37
|
Hello again Funnily enough, throwing more memory at it didn't solve the problem. I was just fooled for a short while. The real problem is that none of UML or Valgrind or my program are running out of memory. Valgrind and my program are running out of memory maps! This fixed it: echo 262144 > /proc/sys/vm/max_map_count And here is where I found the answer: http://uml.harlowhill.com/index.php/Troubleshooting Benjamin Nicholas Nethercote wrote: > On Tue, 24 Jan 2006, Tom Hughes wrote: > >>> The application is a beast taking hundreds of megabytes of dynamic >>> memory. >> >> >> Well that is probably the problem then - error 12 is ENOMEM so most >> likely your program has run out of memory. Don't forget that under >> valgrind it will be using a lot more memory than normal. > > > If you're running Memcheck (the default tool), try running --tool=none, > which will use less memory. > > Nick > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Benjamin C. <ben...@si...> - 2006-01-25 14:44:06
|
Hi everyone The solution was simple: throw more hardware at it. Bought an extra gigabyte and now things are as happy as they should be. Thanks for responding Ben Nicholas Nethercote wrote: > On Tue, 24 Jan 2006, Tom Hughes wrote: > >>> The application is a beast taking hundreds of megabytes of dynamic >>> memory. >> >> >> Well that is probably the problem then - error 12 is ENOMEM so most >> likely your program has run out of memory. Don't forget that under >> valgrind it will be using a lot more memory than normal. > > > If you're running Memcheck (the default tool), try running --tool=none, > which will use less memory. > > Nick > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Cees W. <ce...@pc...> - 2006-01-25 13:38:28
|
>> But is there any way of definining something like?:
>>
>> {
>> <insert a suppression name here>
>> Memcheck:Leak
>> fun:_Znwj
>> ?? 1 or more of any functions
>> fun:RootOfAllEvil
>> }
>
>
> Currently no, sorry.
Thanks Nick, that save for looking any further.
As a workaround I discovered the XML output of valgrind.
That let me do funky filter things like:
<xsl:transform
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0"
>
<xsl:strip-space elements="*" />
<xsl:output method="xml" indent="yes"/>
<!-- match any occurence of RootOfAllEvil -->
<xsl:template match="error[.//fn='RootOfAllEvil']">
<!-- and filter out this kind for RootOfAllEvil -->
<xsl:choose>
<xsl:when test=".//kind[1]='Leak_StillReachable'"/>
<xsl:when test=".//kind[1]='Leak_IndirectlyLost'"/>
<xsl:otherwise>
<xsl:copy-of select="."/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template match="error">
<xsl:copy-of select="."/>
</xsl:template>
<xsl:template match="*">
<xsl:apply-templates select="error"/>
</xsl:template>
</xsl:transform>
--
Cees Wesseling
PCRaster Environmental Software
|
|
From: Christian P. <tr...@ge...> - 2006-01-25 12:59:38
|
On Tuesday 24 January 2006 19:05, Dennis Lubert wrote: > >It is not unknown for people to port apps to Linux just so they > >can use Valgrind on them. =A0That's another possibility. > > Porting VC++ 6.0 code to linux could be a bigger problem though, > since it is known to horribly fail to comply to the iso c++ standard, > as an example it does not following scoping rules for for-loops and > has differente template syntax. best time to revalidate the sources and make it compliant though ;-) |
|
From: Christian P. <tr...@ge...> - 2006-01-25 12:59:04
|
On Wednesday 25 January 2006 10:17, KevinGPO wrote: > That's why I should upgrade to use MS Toolkit 2003 right? > > Anyway, my program is like... millions of lines long and is massive. It > usually takes 30 minutes to compile. 30 minutes to compile are certainly not "millions of lines" in fact, MSVC i= s=20 slow and not that fast. we're having here code with around 35,000 lines that takes (statically link= ed)=20 on MSVC (VS.NET 2005) about 20+ minutes to compile, mostly because it's=20 making heavy use of templates though. Regards, Christian Parpart. |
|
From: Nicholas N. <nj...@cs...> - 2006-01-25 11:07:52
|
On Wed, 25 Jan 2006, Cees wrote:
> But is there any way of definining something like?:
>
> {
> <insert a suppression name here>
> Memcheck:Leak
> fun:_Znwj
> ?? 1 or more of any functions
> fun:RootOfAllEvil
> }
Currently no, sorry.
Nick
|
|
From: Cees <ce...@pc...> - 2006-01-25 10:50:36
|
Hi,
I am trying to write suppression rules for leaks that originate from some
function say RootOfAllEvil.
Below that function there are many leaks but not all at the same stack depth.
AFAIK, I could suppress all _Znwj (C++ new) at depth 1 by doing:
{
<insert a suppression name here>
Memcheck:Leak
fun:_Znwj
fun:*
fun:RootOfAllEvil
}
and add more for depth 2,3, etc.
But is there any way of definining something like?:
{
<insert a suppression name here>
Memcheck:Leak
fun:_Znwj
?? 1 or more of any functions
fun:RootOfAllEvil
}
It sounds so naturraly to me that this is possible, but I am unable to find
information on if this is possible, or that I can achieve the same in another
fashion.
Tanks in advance,
Cees
|
|
From: KevinGPO <kev...@ho...> - 2006-01-25 09:16:32
|
That's why I should upgrade to use MS Toolkit 2003 right? Anyway, my program is like... millions of lines long and is massive. It usually takes 30 minutes to compile. "Dennis Lubert" <pla...@in...> wrote in message news:7.0...@pl...... > At 18:57 24.01.2006, Julian Seward wrote: > >>A research-grade problem, imo. >> >>It is not unknown for people to port apps to Linux just so they >>can use Valgrind on them. That's another possibility. > > Porting VC++ 6.0 code to linux could be a bigger problem though, since it > is known to horribly fail to comply to the iso c++ standard, as an example > it does not following scoping rules for for-loops and has differente > template syntax. > > greets > > Dennis > > > Carpe quod tibi datum est > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 |
|
From: Nicholas N. <nj...@cs...> - 2006-01-24 22:12:53
|
On Tue, 24 Jan 2006, Tom Hughes wrote: >> The application is a beast taking hundreds of megabytes of dynamic memory. > > Well that is probably the problem then - error 12 is ENOMEM so most > likely your program has run out of memory. Don't forget that under > valgrind it will be using a lot more memory than normal. If you're running Memcheck (the default tool), try running --tool=none, which will use less memory. Nick |