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
(1) |
2
|
3
(4) |
4
(3) |
5
(3) |
6
(3) |
|
7
|
8
(2) |
9
(3) |
10
(1) |
11
|
12
|
13
|
|
14
|
15
|
16
(3) |
17
|
18
(8) |
19
(2) |
20
(5) |
|
21
|
22
|
23
|
24
|
25
|
26
|
27
(2) |
|
28
(2) |
29
|
30
|
31
|
|
|
|
|
From: Philippe W. <phi...@sk...> - 2018-10-18 17:44:22
|
On Thu, 2018-10-18 at 14:12 +0200, Julian Seward wrote: > On 18/10/18 13:58, Martin Becker wrote: > > Sure. I am taking snapshots (record_ExeContext) during simulation and want to > > walk through the associated stack traces during finalization. I wanted to use > > apply_ExeContext(), but it is not implemented (valgrind 3.14). OTOH, > > apply_StackTrace() cannot be used, because I cannot access the stack trace > > from the ExeContext. > > > > Maybe I am trying something stupid and completely unplanned here, but to me it > > seems useful to do it that way. I don't want to walk through the stack trace > > during simulation, because what I am doing with it would be very slow. > > There is the problem that a StackTrace is just a bunch of code addresses. > It only has meaning at the point in time where it is created. If you come > back to it later, you might find that some of the addresses in the trace > refer to libraries (.so's) which have been unloaded, and/or even worse, a > different .so has been mapped in to the same memory area. > > An ExeContext combines a StackTrace with an "epoch", which indicates where in > the .so map/unmap event sequence, the StackTrace refers to. You can only > convert a code address (in the StackTrace) into a code location if you have > the epoch too. > > So for this reason I would suggest that a StackTrace is useless to you. It > sounds like you want to do after-the-event processing of their contents > (which sounds reasonable) but for that you need to work with ExeContexts. > > note .. I am not 100% sure of the details about epochs above. Philippe W > will know for sure. Yes, it is a better idea to work with ExeContexts, for the reasons given above. The patch done by Roger to provide Apply_ExeContext seems reasonable to me, I have some comments that I will attach to the bugzilla report. Philippe |
|
From: Martin B. <mar...@tu...> - 2018-10-18 12:30:26
|
On 10/18/2018 02:12 PM, Julian Seward wrote: > On 18/10/18 13:58, Martin Becker wrote: >> Sure. I am taking snapshots (record_ExeContext) during simulation and want to >> walk through the associated stack traces during finalization. I wanted to use >> apply_ExeContext(), but it is not implemented (valgrind 3.14). OTOH, >> apply_StackTrace() cannot be used, because I cannot access the stack trace >> from the ExeContext. >> >> Maybe I am trying something stupid and completely unplanned here, but to me it >> seems useful to do it that way. I don't want to walk through the stack trace >> during simulation, because what I am doing with it would be very slow. > > There is the problem that a StackTrace is just a bunch of code addresses. > It only has meaning at the point in time where it is created. If you come > back to it later, you might find that some of the addresses in the trace > refer to libraries (.so's) which have been unloaded, and/or even worse, a > different .so has been mapped in to the same memory area. > > An ExeContext combines a StackTrace with an "epoch", which indicates where in > the .so map/unmap event sequence, the StackTrace refers to. You can only > convert a code address (in the StackTrace) into a code location if you have > the epoch too. > > So for this reason I would suggest that a StackTrace is useless to you. It > sounds like you want to do after-the-event processing of their contents > (which sounds reasonable) but for that you need to work with ExeContexts. > > note .. I am not 100% sure of the details about epochs above. Philippe W > will know for sure. > > J > Julian, Thanks for the explanation. I have now moved to ExeContexts using Roger Light's recent patches implementing apply_ExeContext() (because it isn't implemented in the latest release). But, in principle apply_StackTrace() should have also worked in valgrind 3.14, since it takes the epoch as parameter. However, I am also not sure ;) My implementation now seems to do what I intended. Regards, Martin |
|
From: Julian S. <js...@ac...> - 2018-10-18 12:12:52
|
On 18/10/18 13:58, Martin Becker wrote: > Sure. I am taking snapshots (record_ExeContext) during simulation and want to > walk through the associated stack traces during finalization. I wanted to use > apply_ExeContext(), but it is not implemented (valgrind 3.14). OTOH, > apply_StackTrace() cannot be used, because I cannot access the stack trace > from the ExeContext. > > Maybe I am trying something stupid and completely unplanned here, but to me it > seems useful to do it that way. I don't want to walk through the stack trace > during simulation, because what I am doing with it would be very slow. There is the problem that a StackTrace is just a bunch of code addresses. It only has meaning at the point in time where it is created. If you come back to it later, you might find that some of the addresses in the trace refer to libraries (.so's) which have been unloaded, and/or even worse, a different .so has been mapped in to the same memory area. An ExeContext combines a StackTrace with an "epoch", which indicates where in the .so map/unmap event sequence, the StackTrace refers to. You can only convert a code address (in the StackTrace) into a code location if you have the epoch too. So for this reason I would suggest that a StackTrace is useless to you. It sounds like you want to do after-the-event processing of their contents (which sounds reasonable) but for that you need to work with ExeContexts. note .. I am not 100% sure of the details about epochs above. Philippe W will know for sure. J |
|
From: Martin B. <mar...@tu...> - 2018-10-18 12:02:24
|
Hi, Yes, I have seen this, but I missed that you have proposed a patch just yesterday. Well, that's excellent timing, and also solves my problem. Thanks! REgards, Martin On 10/18/2018 01:33 PM, Roger Light wrote: > Hi Martin, > > I'm not a valgrind developer. Could you do what you want with > VG_(apply_ExeContext)()? This is a declared as a public tool function, > but with no implementation at the moment. There is an implementation of > it in one of the proposed patches on > https://bugs.kde.org/show_bug.cgi?id=396290 > > Regards, > > Roger > > > > On Thu, 18 Oct 2018 at 11:48, Martin Becker <mar...@tu... > <mailto:mar...@tu...>> wrote: > > Hi developers, > > I am currently creating a new tool for valgrind, and I am lacking one > interface function which I suspect has been forgotten to be declared in > the tool header files. > > Specifically, I want get the StackTrace from an ExeContext. But while > there are getters for n_ips and others, there is no publicly declared > getter for get_ExeContext_StackTrace. It is only made available to the > core in pub_core_execontext.h. Is this an oversight, or should I really > not use this function for some reasons? > > Regards, > Martin > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > <mailto:Val...@li...> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Roger L. <rog...@ce...> - 2018-10-18 12:00:49
|
Hi Martin, I'm not a valgrind developer. Could you do what you want with VG_(apply_ExeContext)()? This is a declared as a public tool function, but with no implementation at the moment. There is an implementation of it in one of the proposed patches on https://bugs.kde.org/show_bug.cgi?id=396290 Regards, Roger On Thu, 18 Oct 2018 at 11:48, Martin Becker <mar...@tu...> wrote: > Hi developers, > > I am currently creating a new tool for valgrind, and I am lacking one > interface function which I suspect has been forgotten to be declared in > the tool header files. > > Specifically, I want get the StackTrace from an ExeContext. But while > there are getters for n_ips and others, there is no publicly declared > getter for get_ExeContext_StackTrace. It is only made available to the > core in pub_core_execontext.h. Is this an oversight, or should I really > not use this function for some reasons? > > Regards, > Martin > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Martin B. <mar...@tu...> - 2018-10-18 11:58:48
|
Sure. I am taking snapshots (record_ExeContext) during simulation and want to walk through the associated stack traces during finalization. I wanted to use apply_ExeContext(), but it is not implemented (valgrind 3.14). OTOH, apply_StackTrace() cannot be used, because I cannot access the stack trace from the ExeContext. Maybe I am trying something stupid and completely unplanned here, but to me it seems useful to do it that way. I don't want to walk through the stack trace during simulation, because what I am doing with it would be very slow. As a side note: I am not planning to record many contexts. Maybe a few dozen or so. Regards, Martin On 10/18/2018 01:02 PM, Julian Seward wrote: > On 18/10/18 12:48, Martin Becker wrote: >> Specifically, I want get the StackTrace from an ExeContext. > > Well, ExeContext is intended to be an abstract type. > > What is it you want to do with the StackTrace, once you get out out > of the ExeContext? It would help to have a bit bigger picture of what > you're trying to achieve here. > > J > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Julian S. <js...@ac...> - 2018-10-18 11:02:18
|
On 18/10/18 12:48, Martin Becker wrote: > Specifically, I want get the StackTrace from an ExeContext. Well, ExeContext is intended to be an abstract type. What is it you want to do with the StackTrace, once you get out out of the ExeContext? It would help to have a bit bigger picture of what you're trying to achieve here. J |
|
From: Martin B. <mar...@tu...> - 2018-10-18 10:48:18
|
Hi developers, I am currently creating a new tool for valgrind, and I am lacking one interface function which I suspect has been forgotten to be declared in the tool header files. Specifically, I want get the StackTrace from an ExeContext. But while there are getters for n_ips and others, there is no publicly declared getter for get_ExeContext_StackTrace. It is only made available to the core in pub_core_execontext.h. Is this an oversight, or should I really not use this function for some reasons? Regards, Martin |