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
(8) |
2
(8) |
3
(15) |
4
(14) |
5
(12) |
6
(40) |
7
(9) |
|
8
(5) |
9
(12) |
10
(9) |
11
(13) |
12
(7) |
13
(7) |
14
(19) |
|
15
(18) |
16
(13) |
17
(16) |
18
(8) |
19
(16) |
20
(16) |
21
(12) |
|
22
(21) |
23
(39) |
24
(27) |
25
(33) |
26
(41) |
27
(17) |
28
(15) |
|
From: Julian S. <js...@ac...> - 2009-02-05 23:12:49
|
> > On further consideration of this, a couple of comments: > > > > 1. Perhaps creating a new struct StackTrace is too much trouble. > > Possibly... if it's variable-sized then you can't stack-allocate it > (can you?) I wouldn't have thought so, no. > > So maybe it's then relevant to consider a representation > > (ips, ips_size, ips_used), where 1 <= ips_size <= VG_DEEPEST_STACKTRACE > > and 1 <= ips_used <= ips_size ? > > Yep. I'll likely do something like this when I get to looking at it. Good. J |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-05 21:29:22
|
On Thu, Feb 5, 2009 at 8:00 PM, Julian Seward <js...@ac...> wrote: > > On further consideration of this, a couple of comments: > > 1. Perhaps creating a new struct StackTrace is too much trouble. Possibly... if it's variable-sized then you can't stack-allocate it (can you?) and that would inconvenience many existing uses. > 2. At the moment the machinery operates by passing around > (ips, n_ips) pairs. Won't the proposed change cause > confusion about the meaning of n_ips? Because then there > are two lengths to record: the size of the ips array, and > the number of actually used entries in it. > > So maybe it's then relevant to consider a representation > (ips, ips_size, ips_used), where 1 <= ips_size <= VG_DEEPEST_STACKTRACE > and 1 <= ips_used <= ips_size ? Yep. I'll likely do something like this when I get to looking at it. N |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-05 21:26:36
|
On Thu, Feb 5, 2009 at 8:14 PM, Julian Seward <js...@ac...> wrote: > > I presume this will eventually show up in the trunk as a result > of Darwin merging activities. Yes, eventually... > Is it also something that should > be pushed to the stable branch? Probably. N |
|
From: <sv...@va...> - 2009-02-05 09:42:01
|
Author: sewardj Date: 2009-02-05 09:41:54 +0000 (Thu, 05 Feb 2009) New Revision: 376 Log: Make valgrind-3.4.1.SVN-9098-1883.tar.bz2 available for testing. Modified: trunk/downloads/current.html Modified: trunk/downloads/current.html =================================================================== --- trunk/downloads/current.html 2009-01-28 05:23:59 UTC (rev 375) +++ trunk/downloads/current.html 2009-02-05 09:41:54 UTC (rev 376) @@ -42,7 +42,17 @@ global arrays. There are many other smaller refinements and improvements.</p> +<div class="hr_brown"><hr/></div> +<p>5 Feb 09: a pre-release snapshot of 3.4.1, +<a href="/downloads/valgrind-3.4.1.SVN-9098-1883.tar.bz2">valgrind-3.4.1.SVN-9098-1883.tar.bz2</a>, +is now available. This fixes some regressions and assertion failures +in debug info reading in 3.4.0, most notably incorrect stack traces +on amd64-linux on older (glibc-2.3 based) systems. Various +other debug info problems are also fixed. Unless further significant +bugs are reported, the final 3.4.1 release will be very similar to +this tarball. Please note that this snapshot is provided for testing +purposes and is not the final 3.4.1 release.</p> <div class="hr_brown"><hr/></div> |
|
From: Julian S. <js...@ac...> - 2009-02-05 09:14:40
|
I presume this will eventually show up in the trunk as a result
of Darwin merging activities. Is it also something that should
be pushed to the stable branch?
J
On Wednesday 04 February 2009, sv...@va... wrote:
> Author: njn
> Date: 2009-02-04 06:50:26 +0000 (Wed, 04 Feb 2009)
> New Revision: 9106
>
> Log:
> Fix a minor bug, whereby a stack entry of zero would cause a "(heap
> allocation functions)" line to be written.
>
> Also invert some comparisons so the constant is first, to minimise the
> chance of assignments in conditions.
>
>
>
> Modified:
> branches/DARWIN/massif/ms_main.c
>
>
> Modified: branches/DARWIN/massif/ms_main.c
> ===================================================================
> --- branches/DARWIN/massif/ms_main.c 2009-02-04 05:14:30 UTC (rev 9105)
> +++ branches/DARWIN/massif/ms_main.c 2009-02-04 06:50:26 UTC (rev 9106)
> @@ -561,7 +561,7 @@
>
> if (hp + n_bytes > hp_lim) {
> hp = (Addr)VG_(am_shadow_alloc)(SUPERBLOCK_SIZE);
> - if (hp == 0)
> + if (0 == hp)
> VG_(out_of_memory_NORETURN)( "massif:perm_malloc",
> SUPERBLOCK_SIZE);
> hp_lim = hp + SUPERBLOCK_SIZE - 1;
> @@ -600,7 +600,7 @@
> // Expand 'children' if necessary.
> tl_assert(parent->n_children <= parent->max_children);
> if (parent->n_children == parent->max_children) {
> - if (parent->max_children == 0) {
> + if (0 == parent->max_children) {
> parent->max_children = 4;
> parent->children = VG_(malloc)( "ms.main.acx.1",
> parent->max_children *
> sizeof(XPt*) ); @@ -654,7 +654,7 @@
> //
> // Nb: We do this once now, rather than once per child, because if we
> do // that the cost of all the divisions adds up to something significant.
> - if (total_szB == 0 && clo_threshold != 0) {
> + if (0 == total_szB && 0 != clo_threshold) {
> sig_child_threshold_szB = 1;
> } else {
> sig_child_threshold_szB = (SizeT)((total_szB * clo_threshold) /
> 100); @@ -1420,7 +1420,7 @@
> if (n_skipped_snapshots_since_last_snapshot > 0) {
> VERB(2, " (skipped %d snapshot%s)",
> n_skipped_snapshots_since_last_snapshot,
> - ( n_skipped_snapshots_since_last_snapshot == 1 ? "" : "s") );
> + ( 1 == n_skipped_snapshots_since_last_snapshot ? "" : "s") );
> }
> VERB_snapshot(2, what, next_snapshot_i);
> n_skipped_snapshots_since_last_snapshot = 0;
> @@ -1994,7 +1994,7 @@
> switch (sxpt->tag) {
> case SigSXPt:
> // Print the SXPt itself.
> - if (sxpt->Sig.ip == 0) {
> + if (0 == depth) {
> ip_desc =
> "(heap allocation functions) malloc/new/new[], --alloc-fns,
> etc."; } else {
> @@ -2094,7 +2094,7 @@
> break;
>
> case InsigSXPt: {
> - Char* s = ( sxpt->Insig.n_xpts == 1 ? "," : "s, all" );
> + Char* s = ( 1 == sxpt->Insig.n_xpts ? "," : "s, all" );
> perc = make_perc(sxpt->szB, snapshot_total_szB);
> FP("%sn0: %lu in %d place%s below massif's threshold (%s)\n",
> depth_str, sxpt->szB, sxpt->Insig.n_xpts, s,
>
>
> ---------------------------------------------------------------------------
>--- Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing
> skills and code to build responsive, highly engaging applications that
> combine the power of local resources and data with the reach of the web.
> Download the Adobe AIR SDK and Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Julian S. <js...@ac...> - 2009-02-05 09:00:47
|
On further consideration of this, a couple of comments:
1. Perhaps creating a new struct StackTrace is too much trouble.
2. At the moment the machinery operates by passing around
(ips, n_ips) pairs. Won't the proposed change cause
confusion about the meaning of n_ips? Because then there
are two lengths to record: the size of the ips array, and
the number of actually used entries in it.
So maybe it's then relevant to consider a representation
(ips, ips_size, ips_used), where 1 <= ips_size <= VG_DEEPEST_STACKTRACE
and 1 <= ips_used <= ips_size ?
J
On Wednesday 04 February 2009, Julian Seward wrote:
> On Wednesday 04 February 2009, Nicholas Nethercote wrote:
> > So it seems we're currently using two distinct methods for indicating
> > the end of a stack trace. First, there's n_ips, and second, there's
> > zero entries. I think we should probably not treat zero entries
> > specially, and just rely on n_ips. If we do want to try to filter
> > out zero addresses, I think it should be done in
> > VG_(get_StackTrace_wrk) and then n_ips adjusted accordingly, rather
> > than doing such filtering subsequently.
> >
> > Thoughts?
>
> [summary of the following: I agree, but perhaps not trivial to fix
> cleanly]
>
> Yes. I suspect you of being correct :-) I believe the semantics of
> this stuff has never really been sorted out properly and perhaps now
> is the time.
>
> AFAIR the stop-at-zero thing is because thread stacks (possibly including
> the main stack, on ppc-linux) are actually terminated with a zero word
> in the IP chain.
>
> At the moment the basic output of VG_(get_StackTrace_wrk) is an array
> of Addrs, which in pub_tool_stacktrace.h is typedefd to "StackTrace".
>
> One obvious thing to do would be to turn StackTrace into a struct thusly:
>
> typedef
> struct { UInt n_ips; /* 1 <= .n_ips <= VG_DEEPEST_STACKTRACE */
> Addr ips[VG_DEEPEST_BACKTRACE] } StackTrace;
>
> so that at least StackTraces are self-describing w.r.t their length.
>
> But I think that might give performance/space problems, because there
> are places -- at least in Helgrind's conflicting-access machinery --
> where the number of frames stored, and hence the length of the array,
> is much less than VG_DEEPEST_BACKTRACE. Have a look at the defn of
> "struct _RCEC".
>
> One way round that is to use the old variable-length struct trick:
>
> typedef
> struct { UInt n_ips; /* 1 <= .n_ips <= VG_DEEPEST_STACKTRACE */
> Addr ips[0] } StackTrace;
>
> which I think might even be legitimate C nowadays. But it then gives
> a problem incorporating a StackTrace into a struct _ExeContext. Or
> perhaps not; it appears struct _ExeContext already uses the variable
> length array trick anyway:
>
> struct _ExeContext {
> struct _ExeContext* chain;
> /* A 32-bit unsigned integer that uniquely identifies this
> ExeContext. Memcheck uses these for origin tracking. Values
> must be nonzero (else Memcheck's origin tracking is hosed), must
> be a multiple of four, and must be unique. Hence they start at
> 4. */
> UInt ecu;
> /* Variable-length array. The size is 'n_ips'; at
> least 1, at most VG_DEEPEST_BACKTRACE. [0] is the current IP,
> [1] is its caller, [2] is the caller of [1], etc. */
> UInt n_ips;
> Addr ips[0];
> };
>
> so we would just replace the last two fields with a StaclTrace.
>
> Anybody know what the Rules of the Game are w.r.t. variable length
> arrays at the end of structs? In particular, if a variable length
> struct (StackTrace) is the last field of another struct (ExeContext),
> does the ExeContext itself become a variable length struct?
>
> J
>
> ---------------------------------------------------------------------------
>--- Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing
> skills and code to build responsive, highly engaging applications that
> combine the power of local resources and data with the reach of the web.
> Download the Adobe AIR SDK and Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <n.n...@gm...> - 2009-02-05 06:41:55
|
On Sun, Feb 1, 2009 at 7:53 AM, Nicholas Nethercote <n.n...@gm...> wrote: > > And yet it doesn't seem to be possible to include Dwarf debug info in > a .a file on Mac. Sigh. Ah... it turns out that 'dwarfdump', the program that shows you debug info in a compiled file, cannot handle .a files. However, Dwarf debug info can be present in .a files and is propagated by the compiler into executables. Which means that building the libreplacemalloc.a library is ok. Nick |
|
From: Tom H. <th...@cy...> - 2009-02-05 03:47:44
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-02-05 03:20:07 GMT 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 == 486 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-02-05 03:44:08
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-02-05 03:05:06 GMT 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 == 477 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-02-05 03:31:59
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-02-05 03:10:03 GMT 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 == 483 tests, 5 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/x86-linux/scalar (stderr) none/tests/mremap2 (stdout) |
|
From: <sv...@va...> - 2009-02-05 01:04:06
|
Author: njn
Date: 2009-02-05 01:04:01 +0000 (Thu, 05 Feb 2009)
New Revision: 9107
Log:
Add some missing '\' end-of-line markers.
Modified:
branches/DARWIN/massif/tests/Makefile.am
Modified: branches/DARWIN/massif/tests/Makefile.am
===================================================================
--- branches/DARWIN/massif/tests/Makefile.am 2009-02-04 06:50:26 UTC (rev 9106)
+++ branches/DARWIN/massif/tests/Makefile.am 2009-02-05 01:04:01 UTC (rev 9107)
@@ -19,7 +19,7 @@
deep-D.post.exp deep-D.stderr.exp deep-D.vgtest \
culling1.stderr.exp culling1.vgtest \
culling2.stderr.exp culling2.vgtest \
- custom_alloc.post.exp custom_alloc.stderr.exp custom_alloc.vgtest
+ custom_alloc.post.exp custom_alloc.stderr.exp custom_alloc.vgtest \
ignored.post.exp ignored.stderr.exp ignored.vgtest \
ignoring.post.exp ignoring.stderr.exp ignoring.vgtest \
insig.post.exp insig.stderr.exp insig.vgtest \
@@ -41,7 +41,7 @@
thresholds_5_10.post.exp thresholds_5_10.stderr.exp thresholds_5_10.vgtest \
thresholds_10_10.post.exp thresholds_10_10.stderr.exp thresholds_10_10.vgtest \
toobig-allocs.stderr.exp toobig-allocs.vgtest \
- zero1.post.exp zero1.stderr.exp zero1.vgtest
+ zero1.post.exp zero1.stderr.exp zero1.vgtest \
zero2.post.exp zero2.stderr.exp zero2.vgtest
AM_CFLAGS = $(WERROR) -Winline -Wall -Wshadow -g $(AM_FLAG_M3264_PRI)
|
|
From: Julian S. <js...@ac...> - 2009-02-05 00:16:14
|
On Wednesday 04 February 2009, Nicholas Nethercote wrote:
> So it seems we're currently using two distinct methods for indicating
> the end of a stack trace. First, there's n_ips, and second, there's
> zero entries. I think we should probably not treat zero entries
> specially, and just rely on n_ips. If we do want to try to filter
> out zero addresses, I think it should be done in
> VG_(get_StackTrace_wrk) and then n_ips adjusted accordingly, rather
> than doing such filtering subsequently.
>
> Thoughts?
[summary of the following: I agree, but perhaps not trivial to fix
cleanly]
Yes. I suspect you of being correct :-) I believe the semantics of
this stuff has never really been sorted out properly and perhaps now
is the time.
AFAIR the stop-at-zero thing is because thread stacks (possibly including
the main stack, on ppc-linux) are actually terminated with a zero word
in the IP chain.
At the moment the basic output of VG_(get_StackTrace_wrk) is an array
of Addrs, which in pub_tool_stacktrace.h is typedefd to "StackTrace".
One obvious thing to do would be to turn StackTrace into a struct thusly:
typedef
struct { UInt n_ips; /* 1 <= .n_ips <= VG_DEEPEST_STACKTRACE */
Addr ips[VG_DEEPEST_BACKTRACE] } StackTrace;
so that at least StackTraces are self-describing w.r.t their length.
But I think that might give performance/space problems, because there
are places -- at least in Helgrind's conflicting-access machinery --
where the number of frames stored, and hence the length of the array,
is much less than VG_DEEPEST_BACKTRACE. Have a look at the defn of
"struct _RCEC".
One way round that is to use the old variable-length struct trick:
typedef
struct { UInt n_ips; /* 1 <= .n_ips <= VG_DEEPEST_STACKTRACE */
Addr ips[0] } StackTrace;
which I think might even be legitimate C nowadays. But it then gives
a problem incorporating a StackTrace into a struct _ExeContext. Or
perhaps not; it appears struct _ExeContext already uses the variable
length array trick anyway:
struct _ExeContext {
struct _ExeContext* chain;
/* A 32-bit unsigned integer that uniquely identifies this
ExeContext. Memcheck uses these for origin tracking. Values
must be nonzero (else Memcheck's origin tracking is hosed), must
be a multiple of four, and must be unique. Hence they start at
4. */
UInt ecu;
/* Variable-length array. The size is 'n_ips'; at
least 1, at most VG_DEEPEST_BACKTRACE. [0] is the current IP,
[1] is its caller, [2] is the caller of [1], etc. */
UInt n_ips;
Addr ips[0];
};
so we would just replace the last two fields with a StaclTrace.
Anybody know what the Rules of the Game are w.r.t. variable length
arrays at the end of structs? In particular, if a variable length
struct (StackTrace) is the last field of another struct (ExeContext),
does the ExeContext itself become a variable length struct?
J
|