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
(10) |
2
(8) |
3
(17) |
4
(28) |
5
(22) |
6
(8) |
|
7
(8) |
8
(22) |
9
(12) |
10
(17) |
11
(14) |
12
(15) |
13
(6) |
|
14
(9) |
15
(9) |
16
(16) |
17
(13) |
18
(18) |
19
(7) |
20
(5) |
|
21
(6) |
22
(5) |
23
(11) |
24
(5) |
25
(11) |
26
(7) |
27
(15) |
|
28
(11) |
29
(12) |
30
(12) |
31
(15) |
|
|
|
|
From: Stephen M.
|
[Off-topic suggestion: you mailer's character-set seems to be configured incorrectly, in that what should be quotation marks in GCC's output are encoded as byte value 0xE2, but the message's headers describe it as ISO-8859-1, a character set in which 0xE2 is "lowercase a with circumflex"] >>>>> "DMR" == Dilip Malinur Ramesh <Dil...@kp...> writes: DMR> Hi, DMR> I have checked out Valgrind code from SVN. DMR> I am trying to add a dummy tool. I am referring "Writing New DMR> Tool" section of the user manual. DMR> I am successful with aclocal, autoheader, automake autoconf and DMR> configure stages, "Make install" is exiting after generating DMR> following errors: DMR> In file included from pub_core_debuglog.h:50, DMR> from launcher.c:48: DMR> ../include/pub_tool_basics.h:47:31: error: libvex_basictypes.h: DMR> No such file or directory The header file libvex_basictypes.h is a necessary part of the VEX library, and you won't be able to compile without it. If you have a correctly checked-out copy of the source code, there should be a "VEX" subdirectory under "valgrind", and this header file should be "VEX/pub/libvex_basictypes.h". VEX is kept in a separate repository that's linked to the Valgrind repository as an "externals definition"; recent versions of subversion should check it out for you automatically, but perhaps you need to upgrade, or check it out separately. Or, if you do have that file, something about the configuration processes is giving you the wrong include paths. DMR> In file included from pub_core_debuglog.h:50, DMR> from launcher.c:48: DMR> ../include/pub_tool_basics.h:77: error: expected "=", ",", ";", "asm" or "__attribute__" before "Off64T" DMR> ../include/pub_tool_basics.h:92: error: expected "=", ",", ";", "asm" or "__attribute__" before "ThreadId" DMR> ../include/pub_tool_basics.h:119: error: expected specifier-qualifier-list before "Bool" DMR> In file included from launcher.c:48: DMR> pub_core_debuglog.h:59: error: expected ")" before "level" DMR> pub_core_debuglog.h:66: error: expected "=", ",", ";", "asm" or "__attribute__" before "vgPlain_debugLog_getLevel" DMR> pub_core_debuglog.h:73: error: expected ")" before "level" DMR> pub_core_debuglog.h:80: error: expected "=", ",", ";", "asm" or "__attribute__" before "vgPlain_debugLog_vprintf" I believe the above errors are all side-effects of the missing include above: GCC is unable to parse other declarations because it is missing the typedefs in that file. DMR> In file included from pub_core_libcproc.h:40, DMR> from launcher.c:49: DMR> ../include/pub_tool_libcproc.h:1: error: stray "\377" in program DMR> ../include/pub_tool_libcproc.h:1: error: stray "\377" in program DMR> ../include/pub_tool_libcproc.h:1: error: stray "\377" in program DMR> ../include/pub_tool_libcproc.h:1: error: stray "\377" in program DMR> ../include/pub_tool_libcproc.h:1: error: stray "\377" in program These errors would seem to indicate that the file in question is corrupted in your copy. I don't think that include file should have any non-ASCII characters in it. DMR> Due to some limitation, I have checked out the code in one system DMR> and had to build it in anther. DMR> Is the error due to this? There's no reason why it shouldn't be possible to build the code on a different machine than you checked it out to. However, since both of the problems above appear to be about having the incorrect contents of the source code directories, it seems likely that the way you copied the files to the build machine is part of the problem you're having. If you were able to build a release that was distributed as a compressed .tar file, you might try using a .tar archive to do your copying. Hope this helps, -- Stephen |
|
From: <js...@ac...> - 2007-10-08 14:24:52
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-10-08 09:00:01 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 220 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: Dirk M. <dm...@gm...> - 2007-10-08 08:59:34
|
On Monday 08 October 2007, Julian Seward wrote: > And so you want > to make clear to users which tools are considered production-ready (you > can rely on the output) and those which aren't (you have to be more careful > in interpreting the output). Ok, in that case a --yes-I-accept-the-disclaimer option that you have to pass via e.g. environment or interactive question during startup would make it more clear to the user that the user should not put too much trust into the report. For me, a mere "exp-" prefix is ambiguous - it can mean that the tool might be unstable, not that it might be incorrect. Dirk |
|
From: Dirk M. <dm...@gm...> - 2007-10-08 08:47:29
|
On Monday 08 October 2007, Nicholas Nethercote wrote: > > some of the experimental tools available require significant (and > > conflicting) changes to the core, which is the reason e.g. distributions > > have troubles packaging the addon experimental tools. > Is that an argument for or against the proposal, or just a general comment? General comment. Although anything that makes this situation better would be highly welcome. > Tools that required big core changes would be less likely to be accepted, > although it would be decided on a case-by-case basis. how do you think should this look like? accept core changes in an #ifdef? accept core changes as long as they can not affect any of the non-experimental tools? Delay addition of an experimental plugin until it doesn't require core changes? > > what about documentation that is written with the exp- prefix, which then > > becomes out of date? broken user habits/custom scripts? > That doesn't worry me particularly. We've broken backward compatibility in > the past on such things. Also, the possibility of a future name change > would be made clear in the documentation on experimental tools, so there'd > be an inherent "user beware" aspect to them. Did you observe at all that someone questions valgrind's (memcheck/core) reputation because they found a bad plugin somewhere? If not so, why treat those experimental plugins as a second class citizen? > I also don't think most of > them would be particularly widely used -- Memcheck accounts for over 80% of > Valgrind usage. Thats true, but I thought one of the aspects of this proposal was to change that :) > Some extra information that might be of interest: at one point Julian and > I were considering having two versions of the distribution, "valgrind" and > "valgrind+extras", due to concerns that if the experimental tools were of a > lower quality that they might hurt Valgrind's reputation. Ok. If the other option is to do two branches (stable and experimental) in addition to the already stable and development code branches, then I'm all against avoiding yet another level of indirection/diversity. Greetings, Dirk |
|
From: Julian S. <js...@ac...> - 2007-10-08 08:42:52
|
> > Might this be a suitable location for omega, too? Assuming someone is OK > > with maintaining it enough to keep it compiling at least? > > If someone volunteered to be a maintainer, it would be suitable, IMO. > Without a maintainer, I'm less keen because simple keep-it-compiling-only > maintenance doesn't work that well in practice, as we saw with Helgrind. I think Omega would be a good candidate for an exp- tool. We do still need a maintainer though, else it will inevitably become unusable as the core changes. Which is a shame as there has been a constant trickle of requests about it over the past few months. With Helgrind we were kinda cheating w.r.t. keeping it compiling. It only compiles because various bits of code (eg, the main instrumentation function) had been #if 0'd or completely removed. And so it doesn't even really compile. J |
|
From: Julian S. <js...@ac...> - 2007-10-08 08:35:14
|
> However, both drd and thrcheck change the core and these changes > overlap. Will the experimental tools be included in Valgrind before or > after thrcheck is merged to the trunk ? Probably around the same time. I expect to add to the trunk, core changes needed to support thrcheck, in the next two weeks or so. In which case that should support drd too. J |
|
From: Julian S. <js...@ac...> - 2007-10-08 08:32:07
|
> > some of the experimental tools available require significant (and > > conflicting) changes to the core, which is the reason e.g. distributions > > have troubles packaging the addon experimental tools. > > Is that an argument for or against the proposal, or just a general comment? > > Tools that required big core changes would be less likely to be accepted, > although it would be decided on a case-by-case basis. Yes, I'd want to be relatively conservative about changing the core. But my impression is that the core/tool interface is pretty effective at insulating tools from the core, and most tools will not need much by way of core changes. For those that do, we could put development on a branch so as to see what core changes will be necessary, then merge to trunk if they seem ok. > > Tagging valgrind assertions/crashdumps/warning output with a clear > > indication that an experimental plugin was run (sort of tainting-concept) > > seems more useful to me. > > We could do that in addition. In addition, yes. But not instead of the exp- name. For the most part tools which are under development don't crash; they just tend to produce results which are sometimes unreliable, inaccurate, etc. And so you want to make clear to users which tools are considered production-ready (you can rely on the output) and those which aren't (you have to be more careful in interpreting the output). J |
|
From: Julian S. <js...@ac...> - 2007-10-08 08:19:03
|
On Monday 08 October 2007 02:33, Nicholas Nethercote wrote: > I altered the OSet interface recently on the trunk to make it much easier > to use it for word-to-word maps. Could you take a look at it and see if it > does the same things as your TC_wordfm.c? It would be good to avoid such > code duplication. Removing the duplication would be good. I've wondered about that from time to time, and saw your commit the other day. Here's a summary of the differences, from looking at the interfaces: I can see that OSetWord makes it easy to do sets of words, but I'm not sure how to use it for word-to-word maps. I would have expected OSetWord_Insert to take two words, a (key,val) pair (a la addToFM), OSetWord_Contains to return a Bool and, if that is True, a Word (a la lookupFM). The behaviour of OSetWord_Insert vs addToFM are different when an existing key is added: the former asserts, the latter replaces the existing binding. That's not a big deal; probably there is a case for having both behaviours. I think the only other frills in WordFM are to do with storage management. * delFromFM returns the (key,value) pair that was deleted, so that the caller can free the key and/or value if either of those point to dynamically allocated memory. Note that the key returned may not necessarily be the same (Word) as the key you asked to delete; they only need to be equal modulo the comparison fn. That's why both the val and the key are made available. * for similar reasons, lookupFM (a la OSetWord_Contains) produces both the existing key and value, if asked to * deleteFM (free up the entire FM) allows calling arbitrary finaliser fns on the keys and values. * I don't think dopyFM is used. It could be removed. That would simplify things. Some time back I spent a couple of hours trying to see if I could implement WordFM on top of OSet (general), but got into difficulties with some of the finer points of storage management. I don't remember any more than that. Perhaps worth revisiting. J |
|
From: Dilip M. R. <Dil...@kp...> - 2007-10-08 07:21:27
|
Hi,
I have checked out Valgrind code from SVN.=20
I am trying to add a dummy tool. I am referring "Writing New Tool" =
section of the user manual.
I am successful with aclocal, autoheader, automake autoconf and =
configure stages, "Make install" is exiting after generating following =
errors:
In file included from pub_core_debuglog.h:50,
from launcher.c:48:
../include/pub_tool_basics.h:47:31: error: libvex_basictypes.h: No such =
file or directory
In file included from pub_core_debuglog.h:50,
from launcher.c:48:
../include/pub_tool_basics.h:77: error: expected =E2=3D=E2, =E2,=E2, =
=E2;=E2, =E2asm=E2 or =E2__attribute__=E2 before =E2Off64T=E2
../include/pub_tool_basics.h:92: error: expected =E2=3D=E2, =E2,=E2, =
=E2;=E2, =E2asm=E2 or =E2__attribute__=E2 before =E2ThreadId=E2
../include/pub_tool_basics.h:119: error: expected =
specifier-qualifier-list before =E2Bool=E2
In file included from launcher.c:48:
pub_core_debuglog.h:59: error: expected =E2)=E2 before =E2level=E2
pub_core_debuglog.h:66: error: expected =E2=3D=E2, =E2,=E2, =E2;=E2, =
=E2asm=E2 or =E2__attribute__=E2 before =E2vgPlain_debugLog_getLevel=E2
pub_core_debuglog.h:73: error: expected =E2)=E2 before =E2level=E2
pub_core_debuglog.h:80: error: expected =E2=3D=E2, =E2,=E2, =E2;=E2, =
=E2asm=E2 or =E2__attribute__=E2 before =E2vgPlain_debugLog_vprintf=E2
In file included from pub_core_libcproc.h:40,
from launcher.c:49:
../include/pub_tool_libcproc.h:1: error: stray =E2\377=E2 in program
../include/pub_tool_libcproc.h:1: error: stray =E2\377=E2 in program
../include/pub_tool_libcproc.h:1: error: stray =E2\377=E2 in program
../include/pub_tool_libcproc.h:1: error: stray =E2\377=E2 in program
../include/pub_tool_libcproc.h:1: error: stray =E2\377=E2 in program
Due to some limitation, I have checked out the code in one system and =
had to build it in anther.=20
Is the error due to this?
But I have successfully built and installed Valgrind using the sources =
downloaded from the "Current releases" section on Valgrind site.
Kindly help me resolve the error.
With kind regards,
Dilip Malinur Ramesh
-----Original Message-----
From: Julian Seward [mailto:js...@ac...]=20
Sent: Thursday, September 06, 2007 8:21 PM
To: Dilip Malinur Ramesh
Subject: Re: Porting valgrind to SH targets
--trace-flags=3D<XXXXXXXX> show generated code? (X =3D 0|1) =
[00000000]
--trace-flags and --profile-flags values (omit the middle space):
1000 0000 show conversion into IR
0100 0000 show after initial opt
0010 0000 show after instrumentation
0001 0000 show after second opt
0000 1000 show after tree building
0000 0100 show selecting insns
0000 0010 show after reg-alloc
0000 0001 show final assembly
(Nb: you need --trace-notbelow with --trace-flags for full =
details)
On Thursday 06 September 2007 10:44, you wrote:
> Hi,
> Sorry for the confusions,
>
> I have a query,
>
> How can I see the IR generated by VEX?
> Is there any command line option we can pass while we invoke valgrind?
>
>
>
> With kind regards,
> Dilip Malinur Ramesh
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: Friday, August 31, 2007 9:13 PM
> To: Dilip Malinur Ramesh
> Subject: Re: Porting valgrind to SH targets
>
>
> Why do you keep sending this mail? I have seen it 4 times now
> and it has been answered twice.
>
> J
>
> On Friday 31 August 2007 09:21, you wrote:
> > Hi,
> > I am trying to port Valgrind to Renesas SuperH targets. Using the
> > resources available on the Valgrind.org, I understood that there
>
> entire
>
> > Valgrind can be logically divided as Core and VEX implementation.
> >
> > Is my understanding correct?
> >
> > If I have to take up this porting activity, how should I have to go
> > about (like legal terms, SVN access etc)?
> >
> > If needed, where can I get additional resources or help (apart from
> > mailing list)?
> >
> > Please give me your valuable advice.
> >
> >
> >
> > With kind regards,
> > Dilip Malinur Ramesh
> >
> > -----Original Message-----
> > From: val...@li...
> > [mailto:val...@li...] On Behalf
>
> Of
>
> > Julian Seward
> > Sent: Wednesday, August 29, 2007 1:03 PM
> > To: Daniel Frampton
> > Cc: val...@li...; Steve Blackburn; =
Chris
> > January; Robin Garner
> > Subject: Re: [Valgrind-developers]Supporting the x86 INT =
instructionin
> > Valgrind
> >
> > On Friday 29 June 2007 11:06, Daniel Frampton wrote:
> > > To add to what Steve said, I saw the implementation of INT3 on the
> > > trunk, but unfortunately we use INT (0xCD) 0x40 - 0x43, and not =
INT3
> > > (0xCC).
> >
> > Just to check what needs to happen: you're expecting Valgrind to
>
> deliver
>
> > SIGSEGV to your application when encountering INT (0xCD) 0x40 - =
0x43,
> > yes?
> >
> > J
>
> =
------------------------------------------------------------------------
>
> > -
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a
>
> browser.
>
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
> =
------------------------------------------------------------------------
>
> > -
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a
>
> browser.
>
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: <sv...@va...> - 2007-10-08 07:20:26
|
Author: njn Date: 2007-10-08 08:20:28 +0100 (Mon, 08 Oct 2007) New Revision: 6964 Log: - update some comments - change some values from SSizeT to SizeT to avoid possible overflow problems Modified: branches/MASSIF2/massif/ms_main.c Modified: branches/MASSIF2/massif/ms_main.c =================================================================== --- branches/MASSIF2/massif/ms_main.c 2007-10-08 06:39:48 UTC (rev 6963) +++ branches/MASSIF2/massif/ms_main.c 2007-10-08 07:20:28 UTC (rev 6964) @@ -31,24 +31,24 @@ // XXX: //--------------------------------------------------------------------------- // Todo: +// - do snapshots on client requests // - Add ability to draw multiple graphs, eg. heap-only, stack-only, total. // Give each graph a title. -// - do peak-taking. // - make file format more generic. Obstacles: // - unit prefixes are not generic // - preset column widths for stats are not generic // - preset column headers are not generic // - "Massif arguments:" line is not generic // - consider 'instructions executed' as a time unit -- more regular than -// ms, less artificial than B +// ms, less artificial than B (bug #121629) // - do a graph-drawing test // - do tests with complicated stack traces -- big ones, ones that require // XCon_redo, ones that exceed --depth, etc. // - test what happens when alloc-fns cover an entire trace +// (it aborts -- should give a warning and do something less drastic?) // - write a good basic test that shows how the tool works, suitable for // documentation // - Check MALLOCLIKE_BLOCK works, write regtest -// - do snapshots on client requests (after peak-taking is done) // - make everything configurable, eg. min/max number of snapshots (which // also determine culling proportion), frequency of detailed snapshots, // etc. @@ -75,36 +75,41 @@ // - dunno, hard to reproduce, ignore // 132132 nor massif --format=html output does not do html entity escaping // - only for HTML output, irrelevant, ignore +// 132950 Heap alloc/usage summary +// - doesn't seem that interesting or general // // FIXED/NOW IRRELEVANT: +// 89061 cra Massif: ms_main.c:485 (get_XCon): Assertion `xpt->max_chi... +// - relevant code now gone +// 143062 cra massif crashes on app exit with signal 8 SIGFPE +// - fixed +// 95483 nor massif feature request: include peak allocation in report +// - implemented in Massif2 +// 92615 nor Write output from Massif at crash +// - this happens unless Massif2 itself crashes +// 121629 add instruction-counting mode for timing +// - time-unit=B is similar, plus I'm considering this above anyway // 142197 nor massif tool ignores --massif:alloc-fn parameters in .valg... // - fixed in trunk // 142491 nor Maximise use of alloc_fns array // - addressed, it's now an OSet and thus unlimited in size -// 89061 cra Massif: ms_main.c:485 (get_XCon): Assertion `xpt->max_chi... +// 144453 (get_XCon): Assertion 'xpt->max_children != 0' failed. // - relevant code now gone -// 143062 cra massif crashes on app exit with signal 8 SIGFPE -// - fixed // -// TODO: -// 92615 -// 95483 -// 121629 -// 132950 -// 134138(?) -// 146252(?) -// 149504 -// 141631 nor Massif: percentages don't add up correctly +// POSSIBLY FIXED BY BETTER SANITY CHECKING, BUT HARD TO TELL: +// 141631 Massif: percentages don't add up correctly // - better sanity-checking should help this greatly -// 142706 nor massif numbers don't seem to add up +// 142706 massif numbers don't seem to add up // - better sanity-checking should help this greatly -// 144453 XXX -// 146456 XXX +// 149504 Assertion hit on alloc_xpt->curr_space >= -space_delta +// - better sanity-checking should help this greatly +// 146456 (update_XCon): Assertion 'xpt->curr_space >= -space_delta' failed. +// - better sanity-checking should help this greatly // // Michael Meeks: // - wants an interactive way to request a dump (callgrind_control-style) // - "profile now" -// - "show me the extra allocations from last-snapshot" +// - "show me the extra allocations since the last snapshot" // - "start/stop logging" (eg. quickly skip boring bits) // // Artur Wisz: @@ -247,13 +252,12 @@ //--- Globals ---// //------------------------------------------------------------// -// These are signed so things are more obvious if they go negative. -static SSizeT heap_szB = 0; // Live heap size -static SSizeT stacks_szB = 0; // Live stacks size +static SizeT heap_szB = 0; // Live heap size +static SizeT stacks_szB = 0; // Live stacks size // This is the total size from the current peak snapshot, or 0 if no peak // snapshot has been taken yet. -static SSizeT peak_snapshot_total_szB = 0; +static SizeT peak_snapshot_total_szB = 0; // Incremented every time memory is allocated/deallocated, by the // allocated/deallocated amount; includes heap, heap-admin and stack |
|
From: Bart V. A. <bar...@gm...> - 2007-10-08 06:58:10
|
On 10/8/07, Nicholas Nethercote <nj...@cs...> wrote: > >> I'm in favor of this proposal, and would appreciate it if drd could be > >> added as an experimental tool. Since the drd and thrcheck tools use > >> different algorithms for detecting data races, it can be interesting to > >> compare the output of the two tools and their performance. > > Yes, DRD is an obvious candidate for inclusion. Can you remind me -- does > it work with the current core? If not, how big are the changes you'd need? The changes needed to get the latest published drd patch working with the current core on the trunk are really minor -- one or two core functions called by drd were renamed in the core. However, both drd and thrcheck change the core and these changes overlap. Will the experimental tools be included in Valgrind before or after thrcheck is merged to the trunk ? Regards, Bart. |
|
From: <sv...@va...> - 2007-10-08 06:39:46
|
Author: njn
Date: 2007-10-08 07:39:48 +0100 (Mon, 08 Oct 2007)
New Revision: 6963
Log:
Implemented peak-taking -- it now records the peak allocation point in
detail, and draws it in the graph with a bar made of '#' chars.
Added:
branches/MASSIF2/massif/tests/peak.c
branches/MASSIF2/massif/tests/peak.post.exp
branches/MASSIF2/massif/tests/peak.stderr.exp
branches/MASSIF2/massif/tests/peak.vgtest
Modified:
branches/MASSIF2/massif/ms_main.c
branches/MASSIF2/massif/ms_print
branches/MASSIF2/massif/tests/Makefile.am
branches/MASSIF2/massif/tests/basic.post.exp
branches/MASSIF2/massif/tests/culling1.stderr.exp
branches/MASSIF2/massif/tests/culling2.stderr.exp
branches/MASSIF2/massif/tests/long-time.post.exp
branches/MASSIF2/massif/tests/one.c
branches/MASSIF2/massif/tests/realloc.post.exp
branches/MASSIF2/massif/tests/realloc.stderr.exp
branches/MASSIF2/massif/tests/realloc.vgtest
Modified: branches/MASSIF2/massif/ms_main.c
===================================================================
--- branches/MASSIF2/massif/ms_main.c 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/ms_main.c 2007-10-08 06:39:48 UTC (rev 6963)
@@ -137,6 +137,10 @@
// respect single quotes...]
// - Explain the --threshold=0 case -- entries with zero bytes must have
// allocated some memory and then freed it all again.
+// - Explain that no peak will be taken if no deallocations are done.
+// - Explain how the stack is computed -- size is assumed to be zero when
+// code starts executing, which isn't true, but reflects what you have
+// control over in a normal program.
//
// Tests:
// - tests/overloaded_new.cpp is there
@@ -233,6 +237,8 @@
static UInt n_getXCon_redo = 0;
static UInt n_cullings = 0;
static UInt n_real_snapshots = 0;
+static UInt n_detailed_snapshots = 0;
+static UInt n_peak_snapshots = 0;
static UInt n_skipped_snapshots = 0;
static UInt n_skipped_snapshots_since_last_snapshot = 0;
@@ -245,6 +251,10 @@
static SSizeT heap_szB = 0; // Live heap size
static SSizeT stacks_szB = 0; // Live stacks size
+// This is the total size from the current peak snapshot, or 0 if no peak
+// snapshot has been taken yet.
+static SSizeT peak_snapshot_total_szB = 0;
+
// Incremented every time memory is allocated/deallocated, by the
// allocated/deallocated amount; includes heap, heap-admin and stack
// memory. An alternative to milliseconds as a unit of program "time".
@@ -832,6 +842,7 @@
typedef
enum {
Normal = 77,
+ Peak,
Unused
}
SnapshotKind;
@@ -871,6 +882,13 @@
return (snapshot->alloc_xpt ? True : False);
}
+static Bool is_uncullable_snapshot(Snapshot* snapshot)
+{
+ return &snapshots[0] == snapshot // First snapshot
+ || &snapshots[next_snapshot_i-1] == snapshot // Last snapshot
+ || snapshot->kind == Peak; // Peak snapshot
+}
+
static void sanity_check_snapshot(Snapshot* snapshot)
{
if (snapshot->alloc_xpt) {
@@ -922,6 +940,7 @@
Snapshot* snapshot = &snapshots[i];
Char* suffix;
switch (snapshot->kind) {
+ case Peak: suffix = "p"; break;
case Normal: suffix = ( is_detailed_snapshot(snapshot) ? "d" : "." ); break;
case Unused: suffix = "u"; break;
default:
@@ -985,7 +1004,8 @@
while (jn < MAX_N_SNAPSHOTS) {
Time timespan = snapshots[jn].time - snapshots[jp].time;
tl_assert(timespan >= 0);
- if (timespan < min_timespan) {
+ // Nb: We never cull the peak snapshot.
+ if (Peak != snapshots[j].kind && timespan < min_timespan) {
min_timespan = timespan;
min_j = j;
}
@@ -1028,15 +1048,31 @@
// two intervals around a snapshot that was under consideration for
// deletion. Here we only measure single intervals because all the
// deletions have occurred.
+ //
+ // But we have to be careful -- some snapshots (eg. snapshot 0, and the
+ // peak snapshot) are uncullable. If two uncullable snapshots end up
+ // next to each other, they'll never be culled (assuming the peak doesn't
+ // change), and the time gap between them will not change. However, the
+ // time between the remaining cullable snapshots will grow ever larger.
+ // This means that the min_timespan found will always be that between the
+ // two uncullable snapshots, and it will be much smaller than it should
+ // be. To avoid this problem, when computing the minimum timespan, we
+ // ignore any timespans between two uncullable snapshots.
tl_assert(next_snapshot_i > 1);
min_timespan = 0x7fffffffffffffffLL;
min_timespan_i = -1;
for (i = 1; i < next_snapshot_i; i++) {
- Time timespan = snapshots[i].time - snapshots[i-1].time;
- tl_assert(timespan >= 0);
- if (timespan < min_timespan) {
- min_timespan = timespan;
- min_timespan_i = i;
+ if (is_uncullable_snapshot(&snapshots[i]) &&
+ is_uncullable_snapshot(&snapshots[i-1]))
+ {
+ VERB(1, "(Ignoring interval %d--%d when computing minimum)", i-1, i);
+ } else {
+ Time timespan = snapshots[i].time - snapshots[i-1].time;
+ tl_assert(timespan >= 0);
+ if (timespan < min_timespan) {
+ min_timespan = timespan;
+ min_timespan_i = i;
+ }
}
}
tl_assert(-1 != min_timespan_i); // Check we found a minimum.
@@ -1121,11 +1157,13 @@
sanity_check_snapshot(snapshot);
// Update stats.
+ if (Peak == kind) n_peak_snapshots++;
+ if (is_detailed) n_detailed_snapshots++;
n_real_snapshots++;
}
-// Take a snapshot, if it's time.
+// Take a snapshot, if it's time, or if we've hit a peak.
static void
maybe_take_snapshot(SnapshotKind kind, Char* what)
{
@@ -1154,6 +1192,21 @@
is_detailed = (0 == n_snapshots_until_next_detailed);
break;
+ case Peak: {
+ // Because we're about to do a deallocation, we're coming down from a
+ // local peak. If it is (a) actually a global peak, and (b) a certain
+ // amount bigger than the previous peak, then we take a peak snapshot.
+ //
+ // XXX: make the percentage configurable
+ SizeT total_szB = heap_szB + clo_heap_admin*n_heap_blocks + stacks_szB;
+ double excess_over_previous_peak = 1.00;
+ if (total_szB <= peak_snapshot_total_szB * excess_over_previous_peak) {
+ return;
+ }
+ is_detailed = True;
+ break;
+ }
+
default:
tl_assert2(0, "maybe_take_snapshot: unrecognised snapshot kind");
}
@@ -1169,6 +1222,26 @@
n_snapshots_until_next_detailed--;
}
+ // Update peak data, if it's a Peak snapshot.
+ if (Peak == kind) {
+ Int i, number_of_peaks_snapshots_found = 0;
+
+ // Sanity check the size, then update our recorded peak.
+ SizeT snapshot_total_szB =
+ snapshot->heap_szB + snapshot->heap_admin_szB + snapshot->stacks_szB;
+ tl_assert(snapshot_total_szB > peak_snapshot_total_szB);
+ peak_snapshot_total_szB = snapshot_total_szB;
+
+ // Find the old peak snapshot, if it exists, and mark it as normal.
+ for (i = 0; i < next_snapshot_i; i++) {
+ if (Peak == snapshots[i].kind) {
+ snapshots[i].kind = Normal;
+ number_of_peaks_snapshots_found++;
+ }
+ }
+ tl_assert(number_of_peaks_snapshots_found <= 1);
+ }
+
// Finish up verbosity and stats stuff.
if (n_skipped_snapshots_since_last_snapshot > 0) {
VERB(1, " (skipped %d snapshot%s)",
@@ -1311,6 +1384,9 @@
}
die_szB = hc->szB;
+ // Maybe take a peak snapshot, since it's a deallocation.
+ maybe_take_snapshot(Peak, "de-PEAK");
+
// Update heap stats
update_heap_stats(-die_szB, /*n_heap_blocks_delta*/-1);
@@ -1352,6 +1428,11 @@
old_szB = hc->szB;
+ // Maybe take a peak snapshot, if it's (effectively) a deallocation.
+ if (new_szB < old_szB) {
+ maybe_take_snapshot(Peak, "re-PEAK");
+ }
+
// Update heap stats
update_heap_stats(new_szB - old_szB, /*n_heap_blocks_delta*/0);
@@ -1481,6 +1562,7 @@
if (have_started_executing_code) {
VERB(2, "<<< die_mem_stack (%ld)", -len);
n_stack_frees++;
+ maybe_take_snapshot(Peak, "stkPEAK");
update_stack_stats(-len);
maybe_take_snapshot(Normal, what);
VERB(2, ">>>");
@@ -1555,7 +1637,6 @@
have_started_executing_code = True;
maybe_take_snapshot(Normal, "startup");
}
-
return bb_in;
}
@@ -1692,7 +1773,7 @@
snapshot->heap_szB + snapshot->heap_admin_szB + snapshot->stacks_szB;
depth_str[0] = '\0'; // Initialise depth_str to "".
- FP("heap_tree=...\n");
+ FP("heap_tree=%s\n", ( Peak == snapshot->kind ? "peak" : "detailed" ));
pp_snapshot_XPt(fd, snapshot->alloc_xpt, 0, depth_str,
depth_str_len, snapshot->heap_szB,
snapshot_total_szB);
@@ -1787,6 +1868,8 @@
VERB(1, "XPt-later-expansions: %u", n_xpt_later_expansions);
VERB(1, "skipped snapshots: %u", n_skipped_snapshots);
VERB(1, "real snapshots: %u", n_real_snapshots);
+ VERB(1, "detailed snapshots: %u", n_detailed_snapshots);
+ VERB(1, "peak snapshots: %u", n_peak_snapshots);
VERB(1, "cullings: %u", n_cullings);
VERB(1, "XCon_redos: %u", n_getXCon_redo);
}
@@ -1811,7 +1894,7 @@
}
if (clo_stacks) {
- // Events to track
+ // Events to track.
VG_(track_new_mem_stack) ( new_mem_stack );
VG_(track_die_mem_stack) ( die_mem_stack );
VG_(track_new_mem_stack_signal) ( new_mem_stack_signal );
Modified: branches/MASSIF2/massif/ms_print
===================================================================
--- branches/MASSIF2/massif/ms_print 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/ms_print 2007-10-08 06:39:48 UTC (rev 6963)
@@ -332,6 +332,8 @@
my @times = ();
my @mem_total_Bs = ();
my @is_detaileds = ();
+ my $peak_num = -1; # An initial value that will be ok if no peak
+ # entry is in the file.
#-------------------------------------------------------------------------
# Read start of input file.
@@ -415,7 +417,11 @@
# snapshot list header to $tmp_file.
if ($heap_tree eq "empty") {
$line = get_line();
- } elsif ($heap_tree eq "...") {
+ } elsif ($heap_tree =~ "(detailed|peak)") {
+ # If "peak", remember the number.
+ if ($heap_tree eq "peak") {
+ $peak_num = $snapshot_num;
+ }
# '1' means it's the top node of the tree.
read_heap_tree(1, "", "", "", $mem_total_B);
@@ -489,6 +495,7 @@
# 10 | ..::::::::: 1 (1 - 1/2) * 10 = 5 1 * 10 = 10
# 0 +-------------
+ my $peak_full_char = '#';
my $detailed_full_char = '@';
my $normal_full_char = ':';
my $half_char = '.';
@@ -517,20 +524,28 @@
($x == $graph_x+1) or die;
$x = $graph_x;
}
-
- # Draw the column only if it's a detailed snapshot, or we don't
- # already have a detailed snapshot's bar in this column -- we don't
- # want to overwrite detailed snapshot's bars with non-detailed
- # snapshot's bars.
+
+ # Draw the column if:
+ # - it's the peak column, or
+ # - it's a detailed column, and we won't overwrite the peak column, or
+ # - it's a normal column, and we won't overwrite the peak column or a
+ # detailed column.
my $should_draw_column =
- ($is_detaileds[$i] or $graph[$x][0] ne $detailed_full_char);
+ (($i == $peak_num) or
+ ($is_detaileds[$i] and $graph[$x][0] ne $peak_full_char) or
+ ($graph[$x][0] ne $peak_full_char and
+ $graph[$x][0] ne $detailed_full_char));
+
if ($should_draw_column) {
# If it's detailed, mark the X-axis. Also choose the full-slot
# char.
my $full_char;
- if ($is_detaileds[$i]) {
- $graph[$x][0] = $detailed_full_char;
+ if ($i == $peak_num) {
+ $full_char = $peak_full_char;
+ $graph[$x][0] = $full_char;
+ } elsif ($is_detaileds[$i]) {
$full_char = $detailed_full_char;
+ $graph[$x][0] = $full_char;
} else {
$full_char = $normal_full_char;
}
@@ -591,6 +606,9 @@
} else {
printf(", $i");
}
+ if ($i == $peak_num) {
+ print(" (peak)");
+ }
}
}
print("]\n");
Modified: branches/MASSIF2/massif/tests/Makefile.am
===================================================================
--- branches/MASSIF2/massif/tests/Makefile.am 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/tests/Makefile.am 2007-10-08 06:39:48 UTC (rev 6963)
@@ -10,9 +10,11 @@
basic.post.exp basic.stderr.exp basic.vgtest \
culling1.stderr.exp culling1.vgtest \
culling2.stderr.exp culling2.vgtest \
+ ignoring.post.exp ignoring.stderr.exp ignoring.vgtest \
long-time.post.exp long-time.stderr.exp long-time.vgtest \
null.post.exp null.stderr.exp null.vgtest \
one.post.exp one.stderr.exp one.vgtest \
+ peak.post.exp peak.stderr.exp peak.vgtest \
realloc.post.exp realloc.stderr.exp realloc.vgtest \
thresholds_0_0.post.exp thresholds_0_0.stderr.exp thresholds_0_0.vgtest \
thresholds_0_10.post.exp thresholds_0_10.stderr.exp thresholds_0_10.vgtest \
@@ -30,9 +32,11 @@
alloc-fns \
basic \
culling1 culling2 \
+ ignoring \
long-time \
null \
one \
+ peak \
realloc \
thresholds \
zero
Modified: branches/MASSIF2/massif/tests/basic.post.exp
===================================================================
--- branches/MASSIF2/massif/tests/basic.post.exp 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/tests/basic.post.exp 2007-10-08 06:39:48 UTC (rev 6963)
@@ -6,31 +6,31 @@
KB
-3.797^ :
- | .:::.
- | .::::::@.
- | .::::::::@::.
- | .@:::::::::@::::.
- | ::@:::::::::@::::::
- | .:::@:::::::::@:::::::.
- | .:::::@:::::::::@:::::::::.
- | .:::::::@:::::::::@:::::::::@:.
- | .:::::::::@:::::::::@:::::::::@:::.
- | :@:::::::::@:::::::::@:::::::::@:::::
- | .::@:::::::::@:::::::::@:::::::::@::::::.
- | .::::@:::::::::@:::::::::@:::::::::@::::::::.
- | .::::::@:::::::::@:::::::::@:::::::::@:::::::::@.
- | .::::::::@:::::::::@:::::::::@:::::::::@:::::::::@::.
- | @:::::::::@:::::::::@:::::::::@:::::::::@:::::::::@::::
- | .:@:::::::::@:::::::::@:::::::::@:::::::::@:::::::::@:::::.
- | .:::@:::::::::@:::::::::@:::::::::@:::::::::@:::::::::@:::::::.
- | .:::::@:::::::::@:::::::::@:::::::::@:::::::::@:::::::::@:::::::::.
- | .:::::::@:::::::::@:::::::::@:::::::::@:::::::::@:::::::::@:::::::::@:.
- 0 +---------@---------@---------@---------@---------@---------@---------@->KB
+3.797^ #
+ | .:#:.
+ | .:::#:::.
+ | .:::::#:::::.
+ | .@::::::#:::::::.
+ | ::@::::::#:::::::::
+ | .:::@::::::#:::::::::@.
+ | .:::::@::::::#:::::::::@::.
+ | .:::::::@::::::#:::::::::@::::.
+ | .:::::::::@::::::#:::::::::@::::::.
+ | :@:::::::::@::::::#:::::::::@::::::::
+ | .::@:::::::::@::::::#:::::::::@:::::::::.
+ | .::::@:::::::::@::::::#:::::::::@:::::::::@:.
+ | .::::::@:::::::::@::::::#:::::::::@:::::::::@:::.
+ | .::::::::@:::::::::@::::::#:::::::::@:::::::::@:::::.
+ | @:::::::::@:::::::::@::::::#:::::::::@:::::::::@:::::::
+ | .:@:::::::::@:::::::::@::::::#:::::::::@:::::::::@::::::::.
+ | .:::@:::::::::@:::::::::@::::::#:::::::::@:::::::::@:::::::::@.
+ | .:::::@:::::::::@:::::::::@::::::#:::::::::@:::::::::@:::::::::@::.
+ | .:::::::@:::::::::@:::::::::@::::::#:::::::::@:::::::::@:::::::::@::::.
+ 0 +---------@---------@---------@------#---------@---------@---------@---->KB
0 7.488
-Number of snapshots: 72
- Detailed snapshots: [9, 19, 29, 39, 49, 59, 69]
+Number of snapshots: 73
+ Detailed snapshots: [9, 19, 29, 37 (peak), 47, 57, 67]
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
@@ -89,62 +89,63 @@
34 3,672 3,672 3,400 272 0
35 3,780 3,780 3,500 280 0
36 3,888 3,888 3,600 288 0
- 37 3,996 3,780 3,500 280 0
- 38 4,104 3,672 3,400 272 0
- 39 4,212 3,564 3,300 264 0
-92.59% (3300B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->92.59% (3300B) 0x80483E5: main (basic.c:14)
+ 37 3,888 3,888 3,600 288 0
+92.59% (3600B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->92.59% (3600B) 0x80483E5: main (basic.c:14)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 40 4,320 3,456 3,200 256 0
- 41 4,428 3,348 3,100 248 0
- 42 4,536 3,240 3,000 240 0
- 43 4,644 3,132 2,900 232 0
- 44 4,752 3,024 2,800 224 0
- 45 4,860 2,916 2,700 216 0
- 46 4,968 2,808 2,600 208 0
- 47 5,076 2,700 2,500 200 0
- 48 5,184 2,592 2,400 192 0
- 49 5,292 2,484 2,300 184 0
-92.59% (2300B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->92.59% (2300B) 0x80483E5: main (basic.c:14)
+ 38 3,996 3,780 3,500 280 0
+ 39 4,104 3,672 3,400 272 0
+ 40 4,212 3,564 3,300 264 0
+ 41 4,320 3,456 3,200 256 0
+ 42 4,428 3,348 3,100 248 0
+ 43 4,536 3,240 3,000 240 0
+ 44 4,644 3,132 2,900 232 0
+ 45 4,752 3,024 2,800 224 0
+ 46 4,860 2,916 2,700 216 0
+ 47 4,968 2,808 2,600 208 0
+92.59% (2600B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->92.59% (2600B) 0x80483E5: main (basic.c:14)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 50 5,400 2,376 2,200 176 0
- 51 5,508 2,268 2,100 168 0
- 52 5,616 2,160 2,000 160 0
- 53 5,724 2,052 1,900 152 0
- 54 5,832 1,944 1,800 144 0
- 55 5,940 1,836 1,700 136 0
- 56 6,048 1,728 1,600 128 0
- 57 6,156 1,620 1,500 120 0
- 58 6,264 1,512 1,400 112 0
- 59 6,372 1,404 1,300 104 0
-92.59% (1300B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->92.59% (1300B) 0x80483E5: main (basic.c:14)
+ 48 5,076 2,700 2,500 200 0
+ 49 5,184 2,592 2,400 192 0
+ 50 5,292 2,484 2,300 184 0
+ 51 5,400 2,376 2,200 176 0
+ 52 5,508 2,268 2,100 168 0
+ 53 5,616 2,160 2,000 160 0
+ 54 5,724 2,052 1,900 152 0
+ 55 5,832 1,944 1,800 144 0
+ 56 5,940 1,836 1,700 136 0
+ 57 6,048 1,728 1,600 128 0
+92.59% (1600B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->92.59% (1600B) 0x80483E5: main (basic.c:14)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 60 6,480 1,296 1,200 96 0
- 61 6,588 1,188 1,100 88 0
- 62 6,696 1,080 1,000 80 0
- 63 6,804 972 900 72 0
- 64 6,912 864 800 64 0
- 65 7,020 756 700 56 0
- 66 7,128 648 600 48 0
- 67 7,236 540 500 40 0
- 68 7,344 432 400 32 0
- 69 7,452 324 300 24 0
-92.59% (300B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->92.59% (300B) 0x80483E5: main (basic.c:14)
+ 58 6,156 1,620 1,500 120 0
+ 59 6,264 1,512 1,400 112 0
+ 60 6,372 1,404 1,300 104 0
+ 61 6,480 1,296 1,200 96 0
+ 62 6,588 1,188 1,100 88 0
+ 63 6,696 1,080 1,000 80 0
+ 64 6,804 972 900 72 0
+ 65 6,912 864 800 64 0
+ 66 7,020 756 700 56 0
+ 67 7,128 648 600 48 0
+92.59% (600B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->92.59% (600B) 0x80483E5: main (basic.c:14)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 70 7,560 216 200 16 0
- 71 7,668 108 100 8 0
+ 68 7,236 540 500 40 0
+ 69 7,344 432 400 32 0
+ 70 7,452 324 300 24 0
+ 71 7,560 216 200 16 0
+ 72 7,668 108 100 8 0
Modified: branches/MASSIF2/massif/tests/culling1.stderr.exp
===================================================================
--- branches/MASSIF2/massif/tests/culling1.stderr.exp 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/tests/culling1.stderr.exp 2007-10-08 06:39:48 UTC (rev 6963)
@@ -425,5 +425,7 @@
Massif: XPt-later-expansions: 0
Massif: skipped snapshots: 51
Massif: real snapshots: 150
+Massif: detailed snapshots: 15
+Massif: peak snapshots: 0
Massif: cullings: 2
Massif: XCon_redos: 0
Modified: branches/MASSIF2/massif/tests/culling2.stderr.exp
===================================================================
--- branches/MASSIF2/massif/tests/culling2.stderr.exp 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/tests/culling2.stderr.exp 2007-10-08 06:39:48 UTC (rev 6963)
@@ -528,5 +528,7 @@
Massif: XPt-later-expansions: 0
Massif: skipped snapshots: 1
Massif: real snapshots: 200
+Massif: detailed snapshots: 20
+Massif: peak snapshots: 0
Massif: cullings: 3
Massif: XCon_redos: 0
Modified: branches/MASSIF2/massif/tests/long-time.post.exp
===================================================================
--- branches/MASSIF2/massif/tests/long-time.post.exp 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/tests/long-time.post.exp 2007-10-08 06:39:48 UTC (rev 6963)
@@ -6,38 +6,52 @@
MB
-2.193^ : @ : @ : @ : @ : @ :
- | : @ : @ : @ : @ : @ :
- | : @ : @ : @ : @ : @ :
- | ........: . . . . . @. . @ . @ :. @. :. @. :.
- | ::::::::: : @ : : : @: : @ : @ :: @: :: @: ::
- | ::::::::: : @ : : : @: : @ : @ :: @: :: @: ::
- | ::::::::: : @ : : : @: : @ : @ :: @: :: @: ::
- | ::::::::: : @ : : : @: : @ : @ :: @: :: @: ::
- | ::::::::: : @ : : : @: : @ : @ :: @: :: @: ::
- | ::::::::: : @ : : : @: : @ : @ :: @: :: @: ::
- |.. ::::::::.::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |:: :::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::.......:::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::@:::::::::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::@:::::::::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::@:::::::::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::@:::::::::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::@:::::::::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::@:::::::::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- |::@:::::::::::::::::::::::: : @ : : : @: :: :@ :: :@ ::::@:::: @: ::
- 0 +--@-----------------------------@------@--@------@-----@-----@-----@--->GB
- 0 11.10
+2.193^#: : : @ : :
+ |#: : : @ : :
+ |#: : : @ : :
+ |#: :. :. . @. :. .
+ |#: :: :: : @: :@ :
+ |#: :: :: : @: :@ :
+ |#: :: :: : @: :@ :
+ |#: :: :: : @: :@ :
+ |#: :: :: : @: :@ :
+ |#: :: :: : @: :@ :
+ |#: :: :: : @: :@ : :. :. :. :. :. :. :. . :. :. :. :
+ |#: :: :: : @: :@ : :: :: :: :: :@ :: :: : :: :@ :: :
+ |#:..................:: :: : @: :@ : ::.::.::.:: :@ :: :: .: :: :@ :: :
+ |#::::@:::::::::::::::: :: : @: :@ : :::::@:::::.:@.::.::.@:.::.:@.::.:
+ |#::::@:::::::::::::::: :: : @: :@ : :::::@:::::::@:::::::@::::::@:::::
+ |#::::@:::::::::::::::: :: : @: :@ : :::::@:::::::@:::::::@::::::@:::::
+ |#::::@:::::::::::::::: :: : @: :@ : :::::@:::::::@:::::::@::::::@:::::
+ |#::::@:::::::::::::::: :: : @: :@ : :::::@:::::::@:::::::@::::::@:::::
+ |#::::@:::::::::::::::: :: : @: :@ : :::::@:::::::@:::::::@::::::@:::::
+ |#::::@:::::::::::::::: :: : @: :@ : :::::@:::::::@:::::::@::::::@:::::
+ 0 +#----@----------------@---@--@---@---@-----@-------@-------@------@---->GB
+ 0 11.15
-Number of snapshots: 97
- Detailed snapshots: [3, 40, 46, 49, 59, 69, 79, 89]
+Number of snapshots: 94
+ Detailed snapshots: [1 (peak), 7, 28, 33, 38, 43, 48, 56, 66, 76, 86]
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
0 0 0 0 0 0
- 1 122,700,000 1,100,000 1,100,000 0 0
- 2 250,700,000 1,100,000 1,100,000 0 0
- 3 399,100,000 900,000 900,000 0 0
+ 1 3,900,000 2,300,000 2,300,000 0 0
+100.00% (2300000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->52.17% (1200000B) 0x8048418: main (long-time.c:15)
+|
+->47.83% (1100000B) 0x80483F7: main (long-time.c:13)
+|
+->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 2 227,900,000 2,300,000 2,300,000 0 0
+ 3 383,100,000 900,000 900,000 0 0
+ 4 607,100,000 900,000 900,000 0 0
+ 5 735,100,000 900,000 900,000 0 0
+ 6 863,100,000 900,000 900,000 0 0
+ 7 991,100,000 900,000 900,000 0 0
100.00% (900000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->100.00% (900000B) 0x8048447: main (long-time.c:18)
|
@@ -46,68 +60,49 @@
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 4 527,100,000 900,000 900,000 0 0
- 5 655,100,000 900,000 900,000 0 0
- 6 783,100,000 900,000 900,000 0 0
- 7 911,100,000 900,000 900,000 0 0
- 8 1,039,100,000 900,000 900,000 0 0
- 9 1,167,100,000 900,000 900,000 0 0
- 10 1,295,100,000 900,000 900,000 0 0
- 11 1,423,100,000 900,000 900,000 0 0
- 12 1,551,100,000 900,000 900,000 0 0
- 13 1,653,000,000 1,200,000 1,200,000 0 0
- 14 1,789,000,000 1,200,000 1,200,000 0 0
- 15 1,925,000,000 1,200,000 1,200,000 0 0
- 16 2,061,000,000 1,200,000 1,200,000 0 0
- 17 2,197,000,000 1,200,000 1,200,000 0 0
- 18 2,333,000,000 1,200,000 1,200,000 0 0
- 19 2,469,000,000 1,200,000 1,200,000 0 0
- 20 2,605,000,000 1,200,000 1,200,000 0 0
- 21 2,741,000,000 1,200,000 1,200,000 0 0
- 22 2,930,700,000 1,100,000 1,100,000 0 0
- 23 3,041,900,000 1,900,000 1,900,000 0 0
- 24 3,153,900,000 1,900,000 1,900,000 0 0
- 25 3,265,900,000 1,900,000 1,900,000 0 0
- 26 3,377,900,000 1,900,000 1,900,000 0 0
- 27 3,489,900,000 1,900,000 1,900,000 0 0
- 28 3,601,900,000 1,900,000 1,900,000 0 0
- 29 3,713,900,000 1,900,000 1,900,000 0 0
- 30 3,825,900,000 1,900,000 1,900,000 0 0
- 31 3,937,900,000 1,900,000 1,900,000 0 0
- 32 4,049,900,000 1,900,000 1,900,000 0 0
- 33 4,161,900,000 1,900,000 1,900,000 0 0
- 34 4,273,900,000 1,900,000 1,900,000 0 0
- 35 4,467,900,000 2,300,000 2,300,000 0 0
- 36 4,688,000,000 0 0 0 0
- 37 4,798,200,000 0 0 0 0
- 38 5,017,900,000 1,900,000 1,900,000 0 0
- 39 5,238,200,000 0 0 0 0
- 40 5,457,900,000 1,900,000 1,900,000 0 0
-100.00% (1900000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->57.89% (1100000B) 0x80483F7: main (long-time.c:13)
-|
-->42.11% (800000B) 0x80483E4: main (long-time.c:12)
-|
+ 8 1,119,100,000 900,000 900,000 0 0
+ 9 1,247,100,000 900,000 900,000 0 0
+ 10 1,375,100,000 900,000 900,000 0 0
+ 11 1,503,100,000 900,000 900,000 0 0
+ 12 1,679,100,000 900,000 900,000 0 0
+ 13 1,807,100,000 900,000 900,000 0 0
+ 14 1,935,100,000 900,000 900,000 0 0
+ 15 2,063,100,000 900,000 900,000 0 0
+ 16 2,191,100,000 900,000 900,000 0 0
+ 17 2,319,100,000 900,000 900,000 0 0
+ 18 2,447,100,000 900,000 900,000 0 0
+ 19 2,575,100,000 900,000 900,000 0 0
+ 20 2,703,100,000 900,000 900,000 0 0
+ 21 2,831,100,000 900,000 900,000 0 0
+ 22 2,959,100,000 900,000 900,000 0 0
+ 23 3,087,100,000 900,000 900,000 0 0
+ 24 3,215,100,000 900,000 900,000 0 0
+ 25 3,342,200,000 0 0 0 0
+ 26 3,467,900,000 2,300,000 2,300,000 0 0
+ 27 3,593,900,000 1,900,000 1,900,000 0 0
+ 28 3,720,000,000 0 0 0 0
+00.00% (0B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 41 5,678,200,000 0 0 0 0
- 42 5,897,900,000 1,900,000 1,900,000 0 0
- 43 6,118,200,000 0 0 0 0
- 44 6,337,900,000 1,900,000 1,900,000 0 0
- 45 6,448,000,000 0 0 0 0
- 46 6,558,200,000 0 0 0 0
+ 29 3,846,200,000 0 0 0 0
+ 30 3,971,900,000 2,300,000 2,300,000 0 0
+ 31 4,097,900,000 1,900,000 1,900,000 0 0
+ 32 4,224,000,000 0 0 0 0
+ 33 4,350,200,000 0 0 0 0
00.00% (0B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 47 6,777,900,000 1,900,000 1,900,000 0 0
- 48 6,888,000,000 0 0 0 0
- 49 7,107,900,000 2,300,000 2,300,000 0 0
+ 34 4,475,900,000 2,300,000 2,300,000 0 0
+ 35 4,601,900,000 1,900,000 1,900,000 0 0
+ 36 4,728,000,000 0 0 0 0
+ 37 4,854,200,000 0 0 0 0
+ 38 4,979,900,000 2,300,000 2,300,000 0 0
100.00% (2300000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->52.17% (1200000B) 0x8048418: main (long-time.c:15)
|
@@ -118,90 +113,106 @@
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 50 7,209,900,000 1,900,000 1,900,000 0 0
- 51 7,312,000,000 0 0 0 0
- 52 7,414,200,000 0 0 0 0
- 53 7,517,000,000 1,200,000 1,200,000 0 0
- 54 7,619,900,000 2,300,000 2,300,000 0 0
- 55 7,721,900,000 1,900,000 1,900,000 0 0
- 56 7,824,000,000 0 0 0 0
- 57 7,926,200,000 0 0 0 0
- 58 8,029,000,000 1,200,000 1,200,000 0 0
- 59 8,131,900,000 2,300,000 2,300,000 0 0
-100.00% (2300000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->52.17% (1200000B) 0x8048418: main (long-time.c:15)
+ 39 5,105,900,000 1,900,000 1,900,000 0 0
+ 40 5,232,000,000 0 0 0 0
+ 41 5,358,200,000 0 0 0 0
+ 42 5,483,900,000 2,300,000 2,300,000 0 0
+ 43 5,609,900,000 1,900,000 1,900,000 0 0
+100.00% (1900000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->57.89% (1100000B) 0x80483F7: main (long-time.c:13)
|
-->47.83% (1100000B) 0x80483F7: main (long-time.c:13)
+->42.11% (800000B) 0x80483E4: main (long-time.c:12)
|
->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 60 8,233,900,000 1,900,000 1,900,000 0 0
- 61 8,336,000,000 0 0 0 0
- 62 8,438,200,000 0 0 0 0
- 63 8,541,000,000 1,200,000 1,200,000 0 0
- 64 8,643,900,000 2,300,000 2,300,000 0 0
- 65 8,745,900,000 1,900,000 1,900,000 0 0
- 66 8,848,000,000 0 0 0 0
- 67 8,950,200,000 0 0 0 0
- 68 9,053,000,000 1,200,000 1,200,000 0 0
- 69 9,155,900,000 2,300,000 2,300,000 0 0
-100.00% (2300000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->52.17% (1200000B) 0x8048418: main (long-time.c:15)
+ 44 5,736,000,000 0 0 0 0
+ 45 5,862,200,000 0 0 0 0
+ 46 5,987,900,000 2,300,000 2,300,000 0 0
+ 47 6,113,900,000 1,900,000 1,900,000 0 0
+ 48 6,240,000,000 0 0 0 0
+00.00% (0B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 49 6,429,000,000 1,200,000 1,200,000 0 0
+ 50 6,554,700,000 1,100,000 1,100,000 0 0
+ 51 6,680,800,000 800,000 800,000 0 0
+ 52 6,807,100,000 900,000 900,000 0 0
+ 53 6,933,000,000 1,200,000 1,200,000 0 0
+ 54 7,058,700,000 1,100,000 1,100,000 0 0
+ 55 7,184,800,000 800,000 800,000 0 0
+ 56 7,311,100,000 900,000 900,000 0 0
+100.00% (900000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->100.00% (900000B) 0x8048447: main (long-time.c:18)
|
-->47.83% (1100000B) 0x80483F7: main (long-time.c:13)
+->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 57 7,437,000,000 1,200,000 1,200,000 0 0
+ 58 7,562,700,000 1,100,000 1,100,000 0 0
+ 59 7,688,800,000 800,000 800,000 0 0
+ 60 7,815,100,000 900,000 900,000 0 0
+ 61 7,941,000,000 1,200,000 1,200,000 0 0
+ 62 8,066,700,000 1,100,000 1,100,000 0 0
+ 63 8,192,800,000 800,000 800,000 0 0
+ 64 8,319,100,000 900,000 900,000 0 0
+ 65 8,445,000,000 1,200,000 1,200,000 0 0
+ 66 8,570,700,000 1,100,000 1,100,000 0 0
+100.00% (1100000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->100.00% (1100000B) 0x80483F7: main (long-time.c:13)
|
->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 70 9,257,900,000 1,900,000 1,900,000 0 0
- 71 9,360,000,000 0 0 0 0
- 72 9,462,200,000 0 0 0 0
- 73 9,565,000,000 1,200,000 1,200,000 0 0
- 74 9,667,900,000 2,300,000 2,300,000 0 0
- 75 9,769,900,000 1,900,000 1,900,000 0 0
- 76 9,872,000,000 0 0 0 0
- 77 9,974,200,000 0 0 0 0
- 78 10,077,000,000 1,200,000 1,200,000 0 0
- 79 10,179,900,000 2,300,000 2,300,000 0 0
-100.00% (2300000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->52.17% (1200000B) 0x8048418: main (long-time.c:15)
+ 67 8,696,800,000 800,000 800,000 0 0
+ 68 8,823,100,000 900,000 900,000 0 0
+ 69 8,949,000,000 1,200,000 1,200,000 0 0
+ 70 9,074,700,000 1,100,000 1,100,000 0 0
+ 71 9,200,800,000 800,000 800,000 0 0
+ 72 9,327,100,000 900,000 900,000 0 0
+ 73 9,453,000,000 1,200,000 1,200,000 0 0
+ 74 9,578,700,000 1,100,000 1,100,000 0 0
+ 75 9,704,800,000 800,000 800,000 0 0
+ 76 9,831,100,000 900,000 900,000 0 0
+100.00% (900000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->100.00% (900000B) 0x8048447: main (long-time.c:18)
|
-->47.83% (1100000B) 0x80483F7: main (long-time.c:13)
-|
->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 80 10,281,900,000 1,900,000 1,900,000 0 0
- 81 10,384,000,000 0 0 0 0
- 82 10,486,200,000 0 0 0 0
- 83 10,589,000,000 1,200,000 1,200,000 0 0
- 84 10,691,900,000 2,300,000 2,300,000 0 0
- 85 10,793,900,000 1,900,000 1,900,000 0 0
- 86 10,896,000,000 0 0 0 0
- 87 10,998,200,000 0 0 0 0
- 88 11,101,000,000 1,200,000 1,200,000 0 0
- 89 11,203,900,000 2,300,000 2,300,000 0 0
-100.00% (2300000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
-->52.17% (1200000B) 0x8048418: main (long-time.c:15)
+ 77 9,957,000,000 1,200,000 1,200,000 0 0
+ 78 10,082,700,000 1,100,000 1,100,000 0 0
+ 79 10,208,800,000 800,000 800,000 0 0
+ 80 10,335,100,000 900,000 900,000 0 0
+ 81 10,461,000,000 1,200,000 1,200,000 0 0
+ 82 10,586,700,000 1,100,000 1,100,000 0 0
+ 83 10,712,800,000 800,000 800,000 0 0
+ 84 10,839,100,000 900,000 900,000 0 0
+ 85 10,965,000,000 1,200,000 1,200,000 0 0
+ 86 11,090,700,000 1,100,000 1,100,000 0 0
+100.00% (1100000B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->100.00% (1100000B) 0x80483F7: main (long-time.c:13)
|
-->47.83% (1100000B) 0x80483F7: main (long-time.c:13)
-|
->00.00% (0B) in 1+ places, all below ms_print's threshold (01.00%)
--------------------------------------------------------------------------------
n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
--------------------------------------------------------------------------------
- 90 11,305,900,000 1,900,000 1,900,000 0 0
- 91 11,408,000,000 0 0 0 0
- 92 11,510,200,000 0 0 0 0
- 93 11,613,000,000 1,200,000 1,200,000 0 0
- 94 11,715,900,000 2,300,000 2,300,000 0 0
- 95 11,817,900,000 1,900,000 1,900,000 0 0
- 96 11,920,000,000 0 0 0 0
+ 87 11,216,800,000 800,000 800,000 0 0
+ 88 11,343,100,000 900,000 900,000 0 0
+ 89 11,469,000,000 1,200,000 1,200,000 0 0
+ 90 11,594,700,000 1,100,000 1,100,000 0 0
+ 91 11,720,800,000 800,000 800,000 0 0
+ 92 11,847,100,000 900,000 900,000 0 0
+ 93 11,973,000,000 1,200,000 1,200,000 0 0
Modified: branches/MASSIF2/massif/tests/one.c
===================================================================
--- branches/MASSIF2/massif/tests/one.c 2007-10-08 05:47:19 UTC (rev 6962)
+++ branches/MASSIF2/massif/tests/one.c 2007-10-08 06:39:48 UTC (rev 6963)
@@ -1,7 +1,6 @@
#include <stdlib.h>
-// Allocate some memory and then deallocate it, to get a nice up-then-down
-// graph.
+// A test for a single allocation.
int main(void)
{
Added: branches/MASSIF2/massif/tests/peak.c
===================================================================
--- branches/MASSIF2/massif/tests/peak.c (rev 0)
+++ branches/MASSIF2/massif/tests/peak.c 2007-10-08 06:39:48 UTC (rev 6963)
@@ -0,0 +1,13 @@
+#include <stdlib.h>
+
+int main(void)
+{
+ int i;
+ for (i = 0; i < 20; i++) {
+ int* p;
+ p = malloc(100);
+ p = malloc(100);
+ free(p);
+ }
+ return 0;
+}
Added: branches/MASSIF2/massif/tests/peak.post.exp
===================================================================
--- branches/MASSIF2/massif/tests/peak.post.exp (rev 0)
+++ branches/MASSIF2/massif/tests/peak.post.exp 2007-10-08 06:39:48 UTC (rev 6963)
@@ -0,0 +1,277 @@
+--------------------------------------------------------------------------------
+Command: ./peak
+Massif arguments: --stacks=no --time-unit=B
+ms_print arguments: massif.out
+--------------------------------------------------------------------------------
+
+
+ KB
+2.215^ #
+ | @ :#:
+ | @ : @::#:
+ | @ :@:: @::#:
+ | @ :@ ::@:: @::#:
+ | @ :@::@ ::@:: @::#:
+ | @ :@: :@::@ ::@:: @::#:
+ | @ : @::@: :@::@ ::@:: @::#:
+ | @ :@:: @::@: :@::@ ::@:: @::#:
+ | @ :@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . .@. :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . . @.:@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . .@.: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . .@ .:@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . .@.:@ ::@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . .@. :@::@ ::@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . . @.:@: :@::@ ::@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . .@.: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | . .@ .:@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ | .@.:@ ::@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::@: :@::@ ::@:: @::#:
+ 0 +--@--@---@---@--@---@--@---@---@--@---@--@---@---@--@---@--@---@---@--#>KB
+ 0 6.328
+
+Number of snapshots: 81
+ Detailed snapshots: [3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59, 63, 67, 71, 75, 79 (peak)]
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 0 0 0 0 0 0
+ 1 108 108 100 8 0
+ 2 216 216 200 16 0
+ 3 216 216 200 16 0
+92.59% (200B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->46.30% (100B) 0x80483DE: main (peak.c:8)
+|
+->46.30% (100B) 0x80483EE: main (peak.c:9)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 4 324 108 100 8 0
+ 5 432 216 200 16 0
+ 6 540 324 300 24 0
+ 7 540 324 300 24 0
+92.59% (300B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->61.73% (200B) 0x80483DE: main (peak.c:8)
+|
+->30.86% (100B) 0x80483EE: main (peak.c:9)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 8 648 216 200 16 0
+ 9 756 324 300 24 0
+ 10 864 432 400 32 0
+ 11 864 432 400 32 0
+92.59% (400B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->69.44% (300B) 0x80483DE: main (peak.c:8)
+|
+->23.15% (100B) 0x80483EE: main (peak.c:9)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 12 972 324 300 24 0
+ 13 1,080 432 400 32 0
+ 14 1,188 540 500 40 0
+ 15 1,188 540 500 40 0
+92.59% (500B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->74.07% (400B) 0x80483DE: main (peak.c:8)
+|
+->18.52% (100B) 0x80483EE: main (peak.c:9)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 16 1,296 432 400 32 0
+ 17 1,404 540 500 40 0
+ 18 1,512 648 600 48 0
+ 19 1,512 648 600 48 0
+92.59% (600B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
+->77.16% (500B) 0x80483DE: main (peak.c:8)
+|
+->15.43% (100B) 0x80483EE: main (peak.c:9)
+
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 20 1,620 540 500 40 0
+ 21 1,728 648 600 48 0
+ 22 1,836 756 700 56 0
+ 23 1...
[truncated message content] |
|
From: <sv...@va...> - 2007-10-08 05:47:18
|
Author: njn
Date: 2007-10-08 06:47:19 +0100 (Mon, 08 Oct 2007)
New Revision: 6962
Log:
Track stack size via {new,die}_mem_stack, rather than iterating over them
with 'thread_stack_next', because it's simpler and more amenable to
peak-taking.
Modified:
branches/MASSIF2/massif/ms_main.c
Modified: branches/MASSIF2/massif/ms_main.c
===================================================================
--- branches/MASSIF2/massif/ms_main.c 2007-10-07 20:40:09 UTC (rev 6961)
+++ branches/MASSIF2/massif/ms_main.c 2007-10-08 05:47:19 UTC (rev 6962)
@@ -242,8 +242,8 @@
//------------------------------------------------------------//
// These are signed so things are more obvious if they go negative.
-static SSizeT sigstacks_szB = 0; // Current signal stacks space sum
-static SSizeT heap_szB = 0; // Live heap size
+static SSizeT heap_szB = 0; // Live heap size
+static SSizeT stacks_szB = 0; // Live stacks size
// Incremented every time memory is allocated/deallocated, by the
// allocated/deallocated amount; includes heap, heap-admin and stack
@@ -1112,15 +1112,7 @@
// Stack(s).
if (clo_stacks) {
- ThreadId tid;
- Addr stack_min, stack_max;
- VG_(thread_stack_reset_iter)();
- while ( VG_(thread_stack_next)(&tid, &stack_min, &stack_max) ) {
- VERB(2, "stack %d: %p -- %p (%ld)",
- tid, stack_min, stack_max, stack_max - stack_min);
- snapshot->stacks_szB += (stack_max - stack_min);
- }
- snapshot->stacks_szB += sigstacks_szB; // Add signal stacks, too
+ snapshot->stacks_szB = stacks_szB;
}
// Rest of snapshot.
@@ -1128,6 +1120,7 @@
snapshot->time = time;
sanity_check_snapshot(snapshot);
+ // Update stats.
n_real_snapshots++;
}
@@ -1461,60 +1454,57 @@
//--- Stacks ---//
//------------------------------------------------------------//
+// We really want the inlining to occur...
+#define INLINE inline __attribute__((always_inline))
+
static void update_stack_stats(SSizeT stack_szB_delta)
{
+ if (stack_szB_delta < 0) tl_assert(stacks_szB >= -stack_szB_delta);
+ stacks_szB += stack_szB_delta;
+
update_alloc_stats(stack_szB_delta);
}
-static void update_sigstack_stats(SSizeT sigstack_szB_delta)
+static INLINE void new_mem_stack_2(Addr a, SizeT len, Char* what)
{
- if (sigstack_szB_delta < 0) tl_assert(sigstacks_szB >= sigstack_szB_delta);
- sigstacks_szB += sigstack_szB_delta;
-
- update_alloc_stats(sigstack_szB_delta);
-}
-
-static void new_mem_stack(Addr a, SizeT len)
-{
if (have_started_executing_code) {
VERB(2, "<<< new_mem_stack (%ld)", len);
n_stack_allocs++;
update_stack_stats(len);
- maybe_take_snapshot(Normal, "stk-new");
+ maybe_take_snapshot(Normal, what);
VERB(2, ">>>");
}
}
-static void die_mem_stack(Addr a, SizeT len)
+static INLINE void die_mem_stack_2(Addr a, SizeT len, Char* what)
{
if (have_started_executing_code) {
VERB(2, "<<< die_mem_stack (%ld)", -len);
n_stack_frees++;
update_stack_stats(-len);
- maybe_take_snapshot(Normal, "stk-die");
+ maybe_take_snapshot(Normal, what);
VERB(2, ">>>");
}
}
+static void new_mem_stack(Addr a, SizeT len)
+{
+ new_mem_stack_2(a, len, "stk-new");
+}
+static void die_mem_stack(Addr a, SizeT len)
+{
+ die_mem_stack_2(a, len, "stk-die");
+}
+
static void new_mem_stack_signal(Addr a, SizeT len)
{
- if (have_started_executing_code) {
- VERB(2, "<<< new_mem_stack_signal (%ld)", len);
- update_sigstack_stats(len);
- maybe_take_snapshot(Normal, "sig-new");
- VERB(2, ">>>");
- }
+ new_mem_stack_2(a, len, "sig-new");
}
static void die_mem_stack_signal(Addr a, SizeT len)
{
- if (have_started_executing_code) {
- VERB(2, "<<< die_mem_stack_signal (%ld)", -len);
- update_sigstack_stats(-len);
- maybe_take_snapshot(Normal, "sig-die");
- VERB(2, ">>>");
- }
+ die_mem_stack_2(a, len, "sig-die");
}
@@ -1822,11 +1812,10 @@
if (clo_stacks) {
// Events to track
- VG_(track_new_mem_stack) ( new_mem_stack );
- VG_(track_die_mem_stack) ( die_mem_stack );
-
- VG_(track_new_mem_stack_signal)( new_mem_stack_signal );
- VG_(track_die_mem_stack_signal)( die_mem_stack_signal );
+ VG_(track_new_mem_stack) ( new_mem_stack );
+ VG_(track_die_mem_stack) ( die_mem_stack );
+ VG_(track_new_mem_stack_signal) ( new_mem_stack_signal );
+ VG_(track_die_mem_stack_signal) ( die_mem_stack_signal );
}
}
@@ -1865,7 +1854,7 @@
0 );
// HP_Chunks
- malloc_list = VG_(HT_construct)( 80021 ); // prime, big
+ malloc_list = VG_(HT_construct)( 80021 ); // prime, big
// Dummy node at top of the context structure.
alloc_xpt = new_XPt(/*ip*/0, /*parent*/NULL);
|
|
From: Tom H. <th...@cy...> - 2007-10-08 02:30:53
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-10-08 03:15:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 256 tests, 27 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-10-08 02:23:09
|
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-10-08 03:10:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 293 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-10-08 02:18:57
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-10-08 03:05:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 293 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-10-08 02:15:39
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-10-08 03:00:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 295 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Nicholas N. <nj...@cs...> - 2007-10-08 00:35:59
|
On Sat, 6 Oct 2007 sv...@va... wrote: > Log: > Speed up nextIterFM by avoiding at least half of the pushes/pops, > by partially evaluating the forwards paths from case 1: and case: 3. I altered the OSet interface recently on the trunk to make it much easier to use it for word-to-word maps. Could you take a look at it and see if it does the same things as your TC_wordfm.c? It would be good to avoid such code duplication. Nick |
|
From: Nicholas N. <nj...@cs...> - 2007-10-08 00:20:12
|
On Fri, 5 Oct 2007, Stephen McCamant wrote: > More broadly, though, I think that similar reasons suggest that other > forms of development on Valgrind could benefit from being closer in > sync with the core, even if it doesn't make sense for them to appear > in the distribution. This includes incomplete architecture and OS > ports, experimental core features, tools that need core changes, and > tools that have only specialized uses. Would it be reasonable to > invite more things like this to live on branches in the SVN > repository? > > I think of the Fjalar/Kvasir code I maintain as falling into the > latter category: it only useful to Daikon users, or potentially to > authors of similar tools, not to general developer-users. And it's > certainly way too easy for it to fall out of sync with the core living > as it does in a local CVS repository. Some of that is general laziness > that won't be helped by any organizational change (merging updates > from the core is a non-automatable task with only delayed benefits), > but I think fostering a culture of more in-sync development would be > good for everyone. I think this idea definitely has merit, and it certainly would make life easier for people like you working on related things. The main thing that concerns me is that if something goes on a branch, is there an implicit idea that it could/would one day go into the core? For example, at http://www.valgrind.org/info/platforms.html we make it clear that we don't want to support a wide range of platforms, because the cost:benefit ratio is not favourable. But some people are working on ports to some of the platforms that we're less interested in (eg. the BSDs). If we made a branch for such ports it might make it harder to maintain this clear position. It's a social/political issue rather than a technical one, perhaps if we had very clear rules it could be workable. Ultimately Julian has the final say, perhaps he has some more to add. Nick |
|
From: <js...@ac...> - 2007-10-08 00:17:04
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-10-08 02:00:01 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 228 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Nicholas N. <nj...@cs...> - 2007-10-08 00:12:18
|
On Sun, 7 Oct 2007, Dirk Mueller wrote: >> Julian and I have been discussing for a while the idea of creating a >> category of "experimental" tools in the Valgrind source tree. These >> would be tools that are not necessarily mature, but may be of interest >> to people. This would make it much easier for users to try out >> experimental tools -- they would be included in the Valgrind distribution >> -- which in turn might accelerate their development. > > some of the experimental tools available require significant (and conflicting) > changes to the core, which is the reason e.g. distributions have troubles > packaging the addon experimental tools. Is that an argument for or against the proposal, or just a general comment? Tools that required big core changes would be less likely to be accepted, although it would be decided on a case-by-case basis. GCC provides a reasonable comparison point -- they have a lot of different platforms, some of which are "primary" and some are "secondary", and (AIUI) they're generally happy to add secondary platforms so long as someone maintains them, but new platforms generally have to fit into the existing framework. >> These tools would be given an "exp-" prefix to their name to indicate >> their experimental nature, and they would be marked clearly as experimental >> on the website and in the manual. Experimental tools could lose the "exp-" >> prefix once they reached a certain level of maturity and popularity. > > what about documentation that is written with the exp- prefix, which then > becomes out of date? broken user habits/custom scripts? That doesn't worry me particularly. We've broken backward compatibility in the past on such things. Also, the possibility of a future name change would be made clear in the documentation on experimental tools, so there'd be an inherent "user beware" aspect to them. I also don't think most of them would be particularly widely used -- Memcheck accounts for over 80% of Valgrind usage. > Tagging valgrind assertions/crashdumps/warning output with a clear indication > that an experimental plugin was run (sort of tainting-concept) seems more > useful to me. We could do that in addition. Some extra information that might be of interest: at one point Julian and I were considering having two versions of the distribution, "valgrind" and "valgrind+extras", due to concerns that if the experimental tools were of a lower quality that they might hurt Valgrind's reputation. But that would make building/testing/installing more complicated, and it would reduce the exposure of the experimental tools, since lots of people would probably not install the extras. The "exp-" prefix seems like a good compromise because it means the experimental tools are widely available, but still making it very clear that they are experimental. Nick |
|
From: Nicholas N. <nj...@cs...> - 2007-10-08 00:01:16
|
On Fri, 5 Oct 2007, Robert Walsh wrote: >> I'm in favor of this proposal, and would appreciate it if drd could be >> added as an experimental tool. Since the drd and thrcheck tools use >> different algorithms for detecting data races, it can be interesting to >> compare the output of the two tools and their performance. Yes, DRD is an obvious candidate for inclusion. Can you remind me -- does it work with the current core? If not, how big are the changes you'd need? > Might this be a suitable location for omega, too? Assuming someone is OK > with maintaining it enough to keep it compiling at least? If someone volunteered to be a maintainer, it would be suitable, IMO. Without a maintainer, I'm less keen because simple keep-it-compiling-only maintenance doesn't work that well in practice, as we saw with Helgrind. Nick |