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: Josef W. <Jos...@gm...> - 2007-10-10 15:12:01
|
On Wednesday 10 October 2007, Nicholas Nethercote wrote: > On Mon, 8 Oct 2007, Dirk Mueller wrote: > > >> 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? > > #ifdefs are a bad idea, IMO. The other two guidelines are possibilities. Yes. FWIW, I am fine with branches. IMHO it is good to have a central place where experimental tools (and according core changes) are available. This way, the chance is higher that a new developer will improve on experimental tools to reach further stability. As tools are linked statically, it should be even possible to install tools using different versions of VG core next to each other; aside from incompatibilities in the launcher, which we would not allow. For experimental tools, IMHO a "exp-" is too cryptic. If you want to go this way, it should be "experimental-...". But instead, I just would abort with a good message when not run with an option "--yes-i-know-this-tool-is-experimental". Being interactive is bad when you want to run the tool from scripts. > Dirk, just to clarify -- you've asked lots of questions about the details, > which is good. But do you think it's a good idea in general? We have > approvals from Bart and Stephen, and an implicit approval from Robert. IMHO providing experimental tools is a good idea. Josef |
|
From: <js...@ac...> - 2007-10-10 14:35:19
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-10-10 09:00: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 == 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: Tom H. <to...@co...> - 2007-10-10 11:05:21
|
In message <200...@ol...>
Robert Goliasz <val...@uu...> wrote:
> I've created a basic alfa version of my patch (attached). It does not yet
> support storing deltas of different symtab versions. Instead, it copies
> a SegInfo struct every time discard_syms_in_range() is called. That leads
> to sometimes insane memory usage, unfortunately. When I ran it with some
> custom freeradius modules of mine, it created about 220 versions of symtabs
> which ate around 400MB of memory.
Excellent.
> I've assumed that a single valgrind (or should I say memcheck?) process is
> single threaded, is that correct? In particular, I make use of globals (which
> I saw were used previously), so any threading within the valgrind process
> would break it totally.
That's fine, as you've probably guessed by all the global variables
that already exist ;-)
Although there will be one thread for each thread in the client
program valgrind is careful to ensure that only one thread will
be running at a time.
The only exception is when one thread is making a system call on
behalf of the client program that may block, in which case another
thread will be allowed to run but the thread making the system call
will wait as soon as the system call is completed until it is given
permission to run again.
> You can also see that I extended the struct _ExeContext with one word that's
> meant to store the version number. Are these extra 4 bytes acceptable in this
> struct? I know there is plenty of them being allocated. If you think we should
> try to minimize it, I could think of doing it somehow dynamically, maybe just
> after this variable-length array that's at the end of it (depending on the
> value of VG_(clo_version_symtabs)). This way, if someone doesn't want
> versioned symtabs, we would not need those extra 4 bytes with every struct
> _ExeContext. Tell me what you think about it.
That sounds like an awful lot of complication for minimal gain to me.
If we assume an average stack trace of 12 entries, then on a 64 bit
system an extra 4 bytes is only a 4% increase in the size of each
execution context.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Robert G. <val...@uu...> - 2007-10-10 10:55:26
|
Following my post on valgrind-users (subject "Dynamically loaded objects -- symbols dissapearing"): I've created a basic alfa version of my patch (attached). It does not yet support storing deltas of different symtab versions. Instead, it copies a SegInfo struct every time discard_syms_in_range() is called. That leads to sometimes insane memory usage, unfortunately. When I ran it with some custom freeradius modules of mine, it created about 220 versions of symtabs which ate around 400MB of memory. I'm planning to extend it further so that somehow magically only changes in SegInfos are stored. The option can be enabled at runtime with --version-symtabs=yes command line argument. I've assumed that a single valgrind (or should I say memcheck?) process is single threaded, is that correct? In particular, I make use of globals (which I saw were used previously), so any threading within the valgrind process would break it totally. You can also see that I extended the struct _ExeContext with one word that's meant to store the version number. Are these extra 4 bytes acceptable in this struct? I know there is plenty of them being allocated. If you think we should try to minimize it, I could think of doing it somehow dynamically, maybe just after this variable-length array that's at the end of it (depending on the value of VG_(clo_version_symtabs)). This way, if someone doesn't want versioned symtabs, we would not need those extra 4 bytes with every struct _ExeContext. Tell me what you think about it. This is not by any means a complete patch, I'm planning on removing repeated code, adding more comments and hopefully making up a way to store deltas of versions of symtabs. Don't apply this yet (but you probably wouldn't anyway). Can I please get write access to SVN so that I can create a branch for my development? I'm not sure if that's possible to do with SVN, but if you could just give me access to one branch (not trunk that is), this would definitely suffice. Thanks -- Robert Goliasz Claranet Ltd. |
|
From: <sv...@va...> - 2007-10-10 07:08:35
|
Author: njn Date: 2007-10-10 08:08:27 +0100 (Wed, 10 Oct 2007) New Revision: 6975 Log: Fix regtest outputs for last commit. Modified: branches/MASSIF2/massif/tests/culling1.stderr.exp branches/MASSIF2/massif/tests/culling2.stderr.exp branches/MASSIF2/massif/tests/deep-B.stderr.exp branches/MASSIF2/massif/tests/deep-C.stderr.exp branches/MASSIF2/massif/tests/realloc.stderr.exp Modified: branches/MASSIF2/massif/tests/culling1.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/culling1.stderr.exp 2007-10-10 05:21:40 UTC (rev 6974) +++ branches/MASSIF2/massif/tests/culling1.stderr.exp 2007-10-10 07:08:27 UTC (rev 6975) @@ -419,10 +419,10 @@ Massif: post-cull S. 48 (t:3510, hp:1950, ad:1560, st:0) Massif: post-cull Sd 49 (t:3582, hp:1990, ad:1592, st:0) Massif: New time interval = 72 (between snapshots 0 and 1) -Massif: allocs: 200 -Massif: zeroallocs: 0 (0%) -Massif: reallocs: 0 -Massif: frees: 0 +Massif: heap allocs: 200 +Massif: heap zero allocs: 0 (0%) +Massif: heap reallocs: 0 +Massif: heap frees: 0 Massif: stack allocs: 0 Massif: stack frees: 0 Massif: XPts: 2 Modified: branches/MASSIF2/massif/tests/culling2.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/culling2.stderr.exp 2007-10-10 05:21:40 UTC (rev 6974) +++ branches/MASSIF2/massif/tests/culling2.stderr.exp 2007-10-10 07:08:27 UTC (rev 6975) @@ -522,10 +522,10 @@ Massif: post-cull S. 48 (t:20678, hp:19110, ad:1568, st:0) Massif: post-cull Sd 49 (t:21293, hp:19701, ad:1592, st:0) Massif: New time interval = 321 (between snapshots 26 and 27) -Massif: allocs: 200 -Massif: zeroallocs: 1 (0%) -Massif: reallocs: 0 -Massif: frees: 0 +Massif: heap allocs: 200 +Massif: heap zero allocs: 1 (0%) +Massif: heap reallocs: 0 +Massif: heap frees: 0 Massif: stack allocs: 0 Massif: stack frees: 0 Massif: XPts: 2 Modified: branches/MASSIF2/massif/tests/deep-B.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/deep-B.stderr.exp 2007-10-10 05:21:40 UTC (rev 6974) +++ branches/MASSIF2/massif/tests/deep-B.stderr.exp 2007-10-10 07:08:27 UTC (rev 6975) @@ -25,10 +25,10 @@ Massif: alloc S. 8 (t:864, hp:800, ad:64, st:0) Massif: alloc Sd 9 (t:972, hp:900, ad:72, st:0) Massif: alloc S. 10 (t:1080, hp:1000, ad:80, st:0) -Massif: allocs: 10 -Massif: zeroallocs: 0 (0%) -Massif: reallocs: 0 -Massif: frees: 0 +Massif: heap allocs: 10 +Massif: heap zero allocs: 0 (0%) +Massif: heap reallocs: 0 +Massif: heap frees: 0 Massif: stack allocs: 0 Massif: stack frees: 0 Massif: XPts: 7 Modified: branches/MASSIF2/massif/tests/deep-C.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/deep-C.stderr.exp 2007-10-10 05:21:40 UTC (rev 6974) +++ branches/MASSIF2/massif/tests/deep-C.stderr.exp 2007-10-10 07:08:27 UTC (rev 6975) @@ -25,10 +25,10 @@ Massif: alloc S. 8 (t:864, hp:800, ad:64, st:0) Massif: alloc Sd 9 (t:972, hp:900, ad:72, st:0) Massif: alloc S. 10 (t:1080, hp:1000, ad:80, st:0) -Massif: allocs: 10 -Massif: zeroallocs: 0 (0%) -Massif: reallocs: 0 -Massif: frees: 0 +Massif: heap allocs: 10 +Massif: heap zero allocs: 0 (0%) +Massif: heap reallocs: 0 +Massif: heap frees: 0 Massif: stack allocs: 0 Massif: stack frees: 0 Massif: XPts: 4 Modified: branches/MASSIF2/massif/tests/realloc.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/realloc.stderr.exp 2007-10-10 05:21:40 UTC (rev 6974) +++ branches/MASSIF2/massif/tests/realloc.stderr.exp 2007-10-10 07:08:27 UTC (rev 6975) @@ -21,10 +21,10 @@ Massif: realloc S. 5 (t:250, hp:150, ad:0, st:0) Massif: de-PEAK Sp 6 (t:250, hp:150, ad:0, st:0) Massif: dealloc S. 7 (t:400, hp:0, ad:0, st:0) -Massif: allocs: 1 -Massif: zeroallocs: 0 (0%) -Massif: reallocs: 4 -Massif: frees: 1 +Massif: heap allocs: 1 +Massif: heap zero allocs: 0 (0%) +Massif: heap reallocs: 3 +Massif: heap frees: 1 Massif: stack allocs: 0 Massif: stack frees: 0 Massif: XPts: 5 |
|
From: <sv...@va...> - 2007-10-10 05:21:41
|
Author: njn
Date: 2007-10-10 06:21:40 +0100 (Wed, 10 Oct 2007)
New Revision: 6974
Log:
Tweak stats and verbosity handling w.r.t. --heap=no.
Modified:
branches/MASSIF2/massif/ms_main.c
Modified: branches/MASSIF2/massif/ms_main.c
===================================================================
--- branches/MASSIF2/massif/ms_main.c 2007-10-10 05:02:43 UTC (rev 6973)
+++ branches/MASSIF2/massif/ms_main.c 2007-10-10 05:21:40 UTC (rev 6974)
@@ -224,10 +224,10 @@
static UInt n_xpts = 0;
static UInt n_dupd_xpts = 0;
static UInt n_dupd_xpts_freed = 0;
-static UInt n_allocs = 0;
-static UInt n_zero_allocs = 0;
-static UInt n_reallocs = 0;
-static UInt n_frees = 0;
+static UInt n_heap_allocs = 0;
+static UInt n_heap_zero_allocs = 0;
+static UInt n_heap_reallocs = 0;
+static UInt n_heap_frees = 0;
static UInt n_stack_allocs = 0;
static UInt n_stack_frees = 0;
static UInt n_xpt_init_expansions = 0;
@@ -1326,17 +1326,10 @@
Bool is_custom_alloc = (NULL != p);
if (szB < 0) return NULL;
- VERB(2, "<<< new_mem_heap (%lu)", szB);
-
- // Update statistics
- n_allocs++;
- if (0 == szB) n_zero_allocs++;
-
// Allocate and zero if necessary
if (!p) {
p = VG_(cli_malloc)( alignB, szB );
if (!p) {
- VERB(2, ">>> (null)");
return NULL;
}
if (is_zeroed) VG_(memset)(p, 0, szB);
@@ -1346,23 +1339,29 @@
hc = VG_(malloc)(sizeof(HP_Chunk));
hc->szB = szB;
hc->data = (Addr)p;
- hc->where = NULL; // paranoia
+ hc->where = NULL;
VG_(HT_add_node)(malloc_list, hc);
if (clo_heap) {
- // Update heap stats
+ VERB(2, "<<< new_mem_heap (%lu)", szB);
+
+ // Update statistics.
+ n_heap_allocs++;
+ if (0 == szB) n_heap_zero_allocs++;
+
+ // Update heap stats.
update_heap_stats(hc->szB, /*n_heap_blocks_delta*/1);
- // Update XTree
+ // Update XTree.
hc->where = get_XCon( tid, is_custom_alloc );
update_XCon(hc->where, szB);
// Maybe take a snapshot.
maybe_take_snapshot(Normal, " alloc");
+
+ VERB(2, ">>>");
}
- VERB(2, ">>>");
-
return p;
}
@@ -1372,39 +1371,38 @@
HP_Chunk* hc;
SizeT die_szB;
- VERB(2, "<<< die_mem_heap");
-
- // Update statistics
- n_frees++;
-
// Remove HP_Chunk from malloc_list
hc = VG_(HT_remove)(malloc_list, (UWord)p);
if (NULL == hc) {
- VERB(2, ">>> (bogus)");
return; // must have been a bogus free()
}
die_szB = hc->szB;
if (clo_heap) {
+ VERB(2, "<<< die_mem_heap");
+
+ // Update statistics
+ n_heap_frees++;
+
// Maybe take a peak snapshot, since it's a deallocation.
maybe_take_snapshot(Peak, "de-PEAK");
- // Update heap stats
+ // Update heap stats.
update_heap_stats(-die_szB, /*n_heap_blocks_delta*/-1);
- // Update XTree, if necessary
+ // Update XTree.
update_XCon(hc->where, -hc->szB);
// Maybe take a snapshot.
maybe_take_snapshot(Normal, "dealloc");
+
+ VERB(2, ">>> (-%lu)", die_szB);
}
// Actually free the chunk, and the heap block (if necessary)
VG_(free)( hc ); hc = NULL;
if (!custom_free)
VG_(cli_free)( p );
-
- VERB(2, ">>> (-%lu)", die_szB);
}
static __inline__
@@ -1415,27 +1413,26 @@
SizeT old_szB;
XPt *old_where, *new_where;
- VERB(2, "<<< renew_mem_heap (%lu)", new_szB);
-
- // Update statistics
- n_reallocs++;
-
// Remove the old block
hc = VG_(HT_remove)(malloc_list, (UWord)p_old);
if (hc == NULL) {
- VERB(2, ">>> (bogus)");
return NULL; // must have been a bogus realloc()
}
old_szB = hc->szB;
if (clo_heap) {
+ VERB(2, "<<< renew_mem_heap (%lu)", new_szB);
+
+ // Update statistics
+ n_heap_reallocs++;
+
// 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.
update_heap_stats(new_szB - old_szB, /*n_heap_blocks_delta*/0);
}
@@ -1454,16 +1451,16 @@
}
if (p_new) {
- old_where = hc->where;
- new_where = get_XCon( tid, /*custom_malloc*/False);
-
- // Update HP_Chunk
+ // Update HP_Chunk.
hc->data = (Addr)p_new;
hc->szB = new_szB;
- hc->where = new_where;
+ old_where = hc->where;
+ hc->where = NULL;
- // Update XPt curr_szB fields
+ // Update XTree.
if (clo_heap) {
+ new_where = get_XCon( tid, /*custom_malloc*/False);
+ hc->where = new_where;
update_XCon(old_where, -old_szB);
update_XCon(new_where, new_szB);
}
@@ -1471,7 +1468,7 @@
// Now insert the new hc (with a possibly new 'data' field) into
// malloc_list. If this realloc() did not increase the memory size, we
- // will have removed and then re-added mc unnecessarily. But that's ok
+ // will have removed and then re-added hc unnecessarily. But that's ok
// because shrinking a block with realloc() is (presumably) much rarer
// than growing it, and this way simplifies the growing case.
VG_(HT_add_node)(malloc_list, hc);
@@ -1479,10 +1476,10 @@
// Maybe take a snapshot.
if (clo_heap) {
maybe_take_snapshot(Normal, "realloc");
+
+ VERB(2, ">>> (%ld)", new_szB - old_szB);
}
- VERB(2, ">>> (%ld)", new_szB - old_szB);
-
return p_new;
}
@@ -1855,12 +1852,12 @@
// Stats
tl_assert(n_xpts > 0); // always have alloc_xpt
- VERB(1, "allocs: %u", n_allocs);
- VERB(1, "zeroallocs: %u (%d%%)",
- n_zero_allocs,
- ( n_allocs ? n_zero_allocs * 100 / n_allocs : 0 ));
- VERB(1, "reallocs: %u", n_reallocs);
- VERB(1, "frees: %u", n_frees);
+ VERB(1, "heap allocs: %u", n_heap_allocs);
+ VERB(1, "heap zero allocs: %u (%d%%)",
+ n_heap_zero_allocs,
+ ( n_heap_allocs ? n_heap_zero_allocs * 100 / n_heap_allocs : 0 ));
+ VERB(1, "heap reallocs: %u", n_heap_reallocs);
+ VERB(1, "heap frees: %u", n_heap_frees);
VERB(1, "stack allocs: %u", n_stack_allocs);
VERB(1, "stack frees: %u", n_stack_frees);
VERB(1, "XPts: %u", n_xpts);
|
|
From: <sv...@va...> - 2007-10-10 05:02:41
|
Author: njn
Date: 2007-10-10 06:02:43 +0100 (Wed, 10 Oct 2007)
New Revision: 6973
Log:
wibble
Modified:
branches/MASSIF2/massif/ms_main.c
Modified: branches/MASSIF2/massif/ms_main.c
===================================================================
--- branches/MASSIF2/massif/ms_main.c 2007-10-10 05:00:19 UTC (rev 6972)
+++ branches/MASSIF2/massif/ms_main.c 2007-10-10 05:02:43 UTC (rev 6973)
@@ -1911,6 +1911,12 @@
VG_(err_bad_option)("--max-snapshots");
}
+ // If we have --heap=no, set --heap-admin to zero, just to make sure we
+ // don't accidentally use a non-zero heap-admin size somewhere.
+ if (!clo_heap) {
+ clo_heap_admin = 0;
+ }
+
// Print alloc-fns, if necessary.
if (VG_(clo_verbosity) > 1) {
i = 1;
|
|
From: <sv...@va...> - 2007-10-10 05:00:18
|
Author: njn
Date: 2007-10-10 06:00:19 +0100 (Wed, 10 Oct 2007)
New Revision: 6972
Log:
- Make --stacks=no the default, because it's slow.
- Handle --heap=no correctly. Add a test for it.
Added:
branches/MASSIF2/massif/tests/no-stack-no-heap.post.exp
branches/MASSIF2/massif/tests/no-stack-no-heap.stderr.exp
branches/MASSIF2/massif/tests/no-stack-no-heap.vgtest
Modified:
branches/MASSIF2/massif/ms_main.c
branches/MASSIF2/massif/tests/Makefile.am
Modified: branches/MASSIF2/massif/ms_main.c
===================================================================
--- branches/MASSIF2/massif/ms_main.c 2007-10-10 03:48:12 UTC (rev 6971)
+++ branches/MASSIF2/massif/ms_main.c 2007-10-10 05:00:19 UTC (rev 6972)
@@ -339,7 +339,7 @@
static Bool clo_heap = True;
static UInt clo_heap_admin = 8;
-static Bool clo_stacks = True;
+static Bool clo_stacks = False;
static UInt clo_depth = 8; // XXX: too low?
static UInt clo_threshold = 100; // 100 == 1%
static UInt clo_time_unit = TimeMS;
@@ -356,6 +356,7 @@
VG_BOOL_CLO(arg, "--heap", clo_heap)
else VG_BOOL_CLO(arg, "--stacks", clo_stacks)
+ // XXX: "--heap-admin= " is accepted!
else VG_NUM_CLO(arg, "--heap-admin", clo_heap_admin)
else VG_NUM_CLO(arg, "--depth", clo_depth)
@@ -381,8 +382,9 @@
{
VG_(printf)(
" --heap=no|yes profile heap blocks [yes]\n"
-" --heap-admin=<number> average admin bytes per heap block [8]\n"
-" --stacks=no|yes profile stack(s) [yes]\n"
+" --heap-admin=<number> average admin bytes per heap block;"
+" ignored if --heap=no [8]\n"
+" --stacks=no|yes profile stack(s) [no]\n"
" --depth=<number> depth of contexts [8]\n"
" --alloc-fn=<name> specify <fn> as an alloc function [empty]\n"
" --threshold=<n> significance threshold, in 100ths of a percent\n"
@@ -1134,17 +1136,13 @@
tl_assert(!is_snapshot_in_use(snapshot));
tl_assert(have_started_executing_code);
- // Heap.
+ // Heap and heap admin.
if (clo_heap) {
snapshot->heap_szB = heap_szB;
if (is_detailed) {
snapshot->alloc_xpt = dup_XTree(alloc_xpt, /*parent*/NULL);
tl_assert(snapshot->alloc_xpt->curr_szB == heap_szB);
}
- }
-
- // Heap admin.
- if (clo_heap_admin > 0) {
snapshot->heap_admin_szB = clo_heap_admin * n_heap_blocks;
}
@@ -1231,7 +1229,8 @@
// 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);
+ tl_assert2(snapshot_total_szB > peak_snapshot_total_szB,
+ "%ld, %ld\n", 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.
@@ -1348,20 +1347,20 @@
hc->szB = szB;
hc->data = (Addr)p;
hc->where = NULL; // paranoia
+ VG_(HT_add_node)(malloc_list, hc);
- // Update heap stats
- update_heap_stats(hc->szB, /*n_heap_blocks_delta*/1);
+ if (clo_heap) {
+ // Update heap stats
+ update_heap_stats(hc->szB, /*n_heap_blocks_delta*/1);
- // Update XTree, if necessary
- if (clo_heap) {
+ // Update XTree
hc->where = get_XCon( tid, is_custom_alloc );
update_XCon(hc->where, szB);
+
+ // Maybe take a snapshot.
+ maybe_take_snapshot(Normal, " alloc");
}
- VG_(HT_add_node)(malloc_list, hc);
- // Maybe take a snapshot.
- maybe_take_snapshot(Normal, " alloc");
-
VERB(2, ">>>");
return p;
@@ -1386,15 +1385,18 @@
}
die_szB = hc->szB;
- // Maybe take a peak snapshot, since it's a deallocation.
- maybe_take_snapshot(Peak, "de-PEAK");
+ if (clo_heap) {
+ // 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);
+ // Update heap stats
+ update_heap_stats(-die_szB, /*n_heap_blocks_delta*/-1);
- // Update XTree, if necessary
- if (clo_heap) {
+ // Update XTree, if necessary
update_XCon(hc->where, -hc->szB);
+
+ // Maybe take a snapshot.
+ maybe_take_snapshot(Normal, "dealloc");
}
// Actually free the chunk, and the heap block (if necessary)
@@ -1402,9 +1404,6 @@
if (!custom_free)
VG_(cli_free)( p );
- // Maybe take a snapshot.
- maybe_take_snapshot(Normal, "dealloc");
-
VERB(2, ">>> (-%lu)", die_szB);
}
@@ -1430,14 +1429,17 @@
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");
+ if (clo_heap) {
+ // 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);
}
- // Update heap stats
- update_heap_stats(new_szB - old_szB, /*n_heap_blocks_delta*/0);
-
+ // Actually do the allocation, if necessary.
if (new_szB <= old_szB) {
// new size is smaller or same; block not moved
p_new = p_old;
@@ -1475,7 +1477,9 @@
VG_(HT_add_node)(malloc_list, hc);
// Maybe take a snapshot.
- maybe_take_snapshot(Normal, "realloc");
+ if (clo_heap) {
+ maybe_take_snapshot(Normal, "realloc");
+ }
VERB(2, ">>> (%ld)", new_szB - old_szB);
Modified: branches/MASSIF2/massif/tests/Makefile.am
===================================================================
--- branches/MASSIF2/massif/tests/Makefile.am 2007-10-10 03:48:12 UTC (rev 6971)
+++ branches/MASSIF2/massif/tests/Makefile.am 2007-10-10 05:00:19 UTC (rev 6972)
@@ -18,6 +18,7 @@
custom_alloc.post.exp custom_alloc.stderr.exp custom_alloc.vgtest
ignoring.post.exp ignoring.stderr.exp ignoring.vgtest \
long-time.post.exp long-time.stderr.exp long-time.vgtest \
+ no-stack-no-heap.post.exp no-stack-no-heap.stderr.exp no-stack-no-heap.vgtest \
null.post.exp null.stderr.exp null.vgtest \
one.post.exp one.stderr.exp one.vgtest \
params.post.exp params.stderr.exp params.vgtest \
Added: branches/MASSIF2/massif/tests/no-stack-no-heap.post.exp
===================================================================
--- branches/MASSIF2/massif/tests/no-stack-no-heap.post.exp (rev 0)
+++ branches/MASSIF2/massif/tests/no-stack-no-heap.post.exp 2007-10-10 05:00:19 UTC (rev 6972)
@@ -0,0 +1,37 @@
+--------------------------------------------------------------------------------
+Command: ./basic
+Massif arguments: --stacks=no --heap=no --time-unit=B
+ms_print arguments: massif.out
+--------------------------------------------------------------------------------
+
+
+ B
+ 1^
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ |
+ 0 +----------------------------------------------------------------------->B
+ 0 1
+
+Number of snapshots: 1
+ Detailed snapshots: []
+--------------------------------------------------------------------------------
+ n time(B) total(B) useful-heap(B) admin-heap(B) stacks(B)
+--------------------------------------------------------------------------------
+ 0 0 0 0 0 0
Added: branches/MASSIF2/massif/tests/no-stack-no-heap.stderr.exp
===================================================================
--- branches/MASSIF2/massif/tests/no-stack-no-heap.stderr.exp (rev 0)
+++ branches/MASSIF2/massif/tests/no-stack-no-heap.stderr.exp 2007-10-10 05:00:19 UTC (rev 6972)
@@ -0,0 +1,2 @@
+
+
Added: branches/MASSIF2/massif/tests/no-stack-no-heap.vgtest
===================================================================
--- branches/MASSIF2/massif/tests/no-stack-no-heap.vgtest (rev 0)
+++ branches/MASSIF2/massif/tests/no-stack-no-heap.vgtest 2007-10-10 05:00:19 UTC (rev 6972)
@@ -0,0 +1,4 @@
+prog: basic
+vgopts: --stacks=no --heap=no --time-unit=B
+post: perl ../../massif/ms_print massif.out
+cleanup: rm massif.out
|
|
From: <sv...@va...> - 2007-10-10 03:48:13
|
Author: njn Date: 2007-10-10 04:48:12 +0100 (Wed, 10 Oct 2007) New Revision: 6971 Log: Forgot to update test outputs for last change, which added C++ allocators to alloc_fns. Modified: branches/MASSIF2/massif/tests/culling1.stderr.exp branches/MASSIF2/massif/tests/culling2.stderr.exp branches/MASSIF2/massif/tests/deep-B.stderr.exp branches/MASSIF2/massif/tests/deep-C.stderr.exp branches/MASSIF2/massif/tests/realloc.stderr.exp Modified: branches/MASSIF2/massif/tests/culling1.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/culling1.stderr.exp 2007-10-09 07:39:05 UTC (rev 6970) +++ branches/MASSIF2/massif/tests/culling1.stderr.exp 2007-10-10 03:48:12 UTC (rev 6971) @@ -4,7 +4,15 @@ Massif: 3: memalign Massif: 4: __builtin_new Massif: 5: __builtin_vec_new -Massif: 6: malloc +Massif: 6: operator new(unsigned) +Massif: 7: operator new[](unsigned) +Massif: 8: operator new(unsigned long) +Massif: 9: operator new[](unsigned long) +Massif: 10: malloc +Massif: 11: operator new(unsigned, std::nothrow_t const&) +Massif: 12: operator new[](unsigned, std::nothrow_t const&) +Massif: 13: operator new(unsigned long, std::nothrow_t const&) +Massif: 14: operator new[](unsigned long, std::nothrow_t const&) Massif: startup S. 0 (t:0, hp:0, ad:0, st:0) Massif: alloc S. 1 (t:18, hp:10, ad:8, st:0) Massif: alloc S. 2 (t:36, hp:20, ad:16, st:0) Modified: branches/MASSIF2/massif/tests/culling2.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/culling2.stderr.exp 2007-10-09 07:39:05 UTC (rev 6970) +++ branches/MASSIF2/massif/tests/culling2.stderr.exp 2007-10-10 03:48:12 UTC (rev 6971) @@ -4,7 +4,15 @@ Massif: 3: memalign Massif: 4: __builtin_new Massif: 5: __builtin_vec_new -Massif: 6: malloc +Massif: 6: operator new(unsigned) +Massif: 7: operator new[](unsigned) +Massif: 8: operator new(unsigned long) +Massif: 9: operator new[](unsigned long) +Massif: 10: malloc +Massif: 11: operator new(unsigned, std::nothrow_t const&) +Massif: 12: operator new[](unsigned, std::nothrow_t const&) +Massif: 13: operator new(unsigned long, std::nothrow_t const&) +Massif: 14: operator new[](unsigned long, std::nothrow_t const&) Massif: startup S. 0 (t:0, hp:0, ad:0, st:0) Massif: alloc S. 1 (t:8, hp:0, ad:8, st:0) Massif: alloc S. 2 (t:17, hp:1, ad:16, st:0) Modified: branches/MASSIF2/massif/tests/deep-B.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/deep-B.stderr.exp 2007-10-09 07:39:05 UTC (rev 6970) +++ branches/MASSIF2/massif/tests/deep-B.stderr.exp 2007-10-10 03:48:12 UTC (rev 6971) @@ -5,7 +5,15 @@ Massif: 4: memalign Massif: 5: __builtin_new Massif: 6: __builtin_vec_new -Massif: 7: malloc +Massif: 7: operator new(unsigned) +Massif: 8: operator new[](unsigned) +Massif: 9: operator new(unsigned long) +Massif: 10: operator new[](unsigned long) +Massif: 11: malloc +Massif: 12: operator new(unsigned, std::nothrow_t const&) +Massif: 13: operator new[](unsigned, std::nothrow_t const&) +Massif: 14: operator new(unsigned long, std::nothrow_t const&) +Massif: 15: operator new[](unsigned long, std::nothrow_t const&) Massif: startup S. 0 (t:0, hp:0, ad:0, st:0) Massif: alloc S. 1 (t:108, hp:100, ad:8, st:0) Massif: alloc S. 2 (t:216, hp:200, ad:16, st:0) Modified: branches/MASSIF2/massif/tests/deep-C.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/deep-C.stderr.exp 2007-10-09 07:39:05 UTC (rev 6970) +++ branches/MASSIF2/massif/tests/deep-C.stderr.exp 2007-10-10 03:48:12 UTC (rev 6971) @@ -5,7 +5,15 @@ Massif: 4: memalign Massif: 5: __builtin_new Massif: 6: __builtin_vec_new -Massif: 7: malloc +Massif: 7: operator new(unsigned) +Massif: 8: operator new[](unsigned) +Massif: 9: operator new(unsigned long) +Massif: 10: operator new[](unsigned long) +Massif: 11: malloc +Massif: 12: operator new(unsigned, std::nothrow_t const&) +Massif: 13: operator new[](unsigned, std::nothrow_t const&) +Massif: 14: operator new(unsigned long, std::nothrow_t const&) +Massif: 15: operator new[](unsigned long, std::nothrow_t const&) Massif: startup S. 0 (t:0, hp:0, ad:0, st:0) Massif: alloc S. 1 (t:108, hp:100, ad:8, st:0) Massif: alloc S. 2 (t:216, hp:200, ad:16, st:0) Modified: branches/MASSIF2/massif/tests/realloc.stderr.exp =================================================================== --- branches/MASSIF2/massif/tests/realloc.stderr.exp 2007-10-09 07:39:05 UTC (rev 6970) +++ branches/MASSIF2/massif/tests/realloc.stderr.exp 2007-10-10 03:48:12 UTC (rev 6971) @@ -4,7 +4,15 @@ Massif: 3: memalign Massif: 4: __builtin_new Massif: 5: __builtin_vec_new -Massif: 6: malloc +Massif: 6: operator new(unsigned) +Massif: 7: operator new[](unsigned) +Massif: 8: operator new(unsigned long) +Massif: 9: operator new[](unsigned long) +Massif: 10: malloc +Massif: 11: operator new(unsigned, std::nothrow_t const&) +Massif: 12: operator new[](unsigned, std::nothrow_t const&) +Massif: 13: operator new(unsigned long, std::nothrow_t const&) +Massif: 14: operator new[](unsigned long, std::nothrow_t const&) Massif: startup S. 0 (t:0, hp:0, ad:0, st:0) Massif: alloc S. 1 (t:100, hp:100, ad:0, st:0) Massif: realloc S. 2 (t:100, hp:100, ad:0, st:0) |
|
From: Tom H. <th...@cy...> - 2007-10-10 02:30:39
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-10-10 03:15: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 == 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-10 02:23:12
|
Nightly build on dellow ( x86_64, Fedora 7 ) started at 2007-10-10 03:10:04 BST Results differ 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) ================================================= == Results 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, 3 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) none/tests/pth_detached (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Oct 10 03:16:47 2007 --- new.short Wed Oct 10 03:23:13 2007 *************** *** 8,10 **** ! == 293 tests, 4 stderr failures, 3 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 293 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 15,17 **** none/tests/mremap2 (stdout) - none/tests/pth_detached (stdout) --- 15,16 ---- |
|
From: Tom H. <th...@cy...> - 2007-10-10 02:19:30
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-10-10 03:05:06 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-10 02:16:07
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-10-10 03:00:03 BST Results differ 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, 2 stdout failures, 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) none/tests/tls (stdout) ================================================= == Results 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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Oct 10 03:09:15 2007 --- new.short Wed Oct 10 03:16:01 2007 *************** *** 8,10 **** ! == 295 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 295 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) *************** *** 16,17 **** --- 16,18 ---- none/tests/mremap2 (stdout) + none/tests/tls (stdout) |
|
From: Robert W. <rj...@du...> - 2007-10-10 01:00:24
|
I'm OK with the idea - nothing implicit about that :-)
Not that I'm happy to whip this dead horse again, but one thing
that's kind of annoying is that a lot of this is working around
subversion. Subversion doesn't do branch updating well, so the
option to "create a branch for experimental tools that require core
changes" involves a lot more maintenance work than with a properly
distributed revision control system. Changesets have to be manually
merged and something outside the system needs to remember what was
merged so consistency can be maintained.
Here's a thought: if we're stuck with subversion, how about
maintaining core changes (and the experimental tools, too) as patches
managed by a patch management system like quilt?
http://savannah.nongnu.org/projects/quilt
Regards,
Robert.
|
|
From: Dirk M. <dm...@gm...> - 2007-10-10 00:25:43
|
On Wednesday 10 October 2007, Nicholas Nethercote wrote: > Dirk, just to clarify -- you've asked lots of questions about the details, > which is good. But do you think it's a good idea in general? Yes of course, although except for the "exp" prefix, as pointed out already (experimental could mean a lot of different things, and the clear message "do not trust this plugins output" is imho not expressed by it). but as you said - the details need to be worked out. I just tried to discuss them to see that it really is a good idea in general :) Thanks, Dirk |
|
From: <js...@ac...> - 2007-10-10 00:17:35
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-10-10 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-10 00:16:47
|
On Mon, 8 Oct 2007, Dirk Mueller wrote: >> 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? #ifdefs are a bad idea, IMO. The other two guidelines are possibilities. There won't be a hard-and-fast rule. For example, I think Bart wants/needs some minor changes for DRD. These seem pretty reasonable, and they would improve DRD's messages, and they're not likely to screw anything else up, so they're fine. Stephen's Fjalar changes (mostly to do with better debug info reading, IIUC) are much larger, and so less likely to be accepted, although if they are generally useful they could be. They would certainly require more scrutiny. Perhaps they could live in a branch for a while. In general, small changes are more likely to be acceptable than large changes, and general features are more likely to be acceptable than features that are more tool-specific. >>> 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? No, but it's a possibility, and the "exp-" prefix is an attempt to avoid it. > If not so, why treat those experimental plugins as a second class citizen? Because they are second class citizens -- they haven't been widely used. Once they have been, if they seem good enough, the can be promoted to non-exp status. Dirk, just to clarify -- you've asked lots of questions about the details, which is good. But do you think it's a good idea in general? We have approvals from Bart and Stephen, and an implicit approval from Robert. Nick |