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
(5) |
2
(16) |
3
(23) |
|
4
(13) |
5
(1) |
6
(1) |
7
(17) |
8
(18) |
9
(14) |
10
(12) |
|
11
|
12
(6) |
13
(19) |
14
(4) |
15
(7) |
16
(30) |
17
(12) |
|
18
(2) |
19
(13) |
20
(3) |
21
(3) |
22
(17) |
23
(16) |
24
(5) |
|
25
(14) |
26
(15) |
27
(4) |
28
(15) |
29
(16) |
30
(16) |
31
(15) |
|
From: Milind C. <Mil...@ri...> - 2013-08-14 15:44:50
|
Resending my question. Is this the right mailing list to ask valgrind internals question? On Tue, Aug 13, 2013 at 12:19 PM, Milind Chabbi <Mil...@ri...>wrote: > Hello, > > I am considering using Valgrind for a heavy-weight instrumentation > that would instrument each memory access. > For detailed information about the access, I want to collect the full > call path of each access. > Can someone tell me (at the high-level) what call path collection > technique exists in Valgrind ? and give me some details of the feature > such as algorithmic complexity of getting the call stack esp. for each > instruction. Is it done using a stack unwinding technique or it is > built on-the-fly via call-ret instructions? How is a call path > represented (is it an identifier to a call path object that can be > queried at a later time) ? > > Thanks > Milind > |
|
From: Maynard J. <may...@us...> - 2013-08-14 12:51:39
|
On 08/13/2013 03:03 PM, Florian Krohm wrote: > On 08/13/2013 09:51 PM, Maynard Johnson wrote: >> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: Sorry, but I forgot to say yesterday that I was only seeing this error on my Intel Core 2 Duo laptop. The current valgrind from SVN trunk worked OK on my ppc64 box. I'm at a different work location today and using a Sandybridge laptop (Intel Core i7) -- and oddly, I cannot reproduce the error, using the same JVM. -Maynard >> >> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >> ==18410== Nulgrind, the minimal Valgrind tool >> ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >> ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >> ==18410== Command: java ThreadLoop 1 >> ==18410== >> --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >> --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 >> >> valgrind: the 'impossible' happened: >> Killed by fatal signal >> ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) >> ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) > > I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, > the faulting address. Looks as if deepCopyIRExprVec does not handle the > special expressions introduced recently. There may be other places. I > haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. > > Florian > > |
|
From: Florian K. <fl...@ei...> - 2013-08-14 12:30:58
|
On 08/14/2013 10:31 AM, Julian Seward wrote: > On 08/13/2013 10:03 PM, Florian Krohm wrote: > >> I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, >> the faulting address. Looks as if deepCopyIRExprVec does not handle the >> special expressions introduced recently. > > I bet you are exactly right about that. Also shallowCopyIRExprVec has the > same problem. Not really, as that function just copies the pointers of the vector elements. Nor does deepCopyIRExprVec, as I said earlier. The function that has the problem is deepCopyIRExpr. It needs if (UNLIKELY(is_IRExprP__VECRET_or_BBPTR(e))) return e; at the beginning. Certain utility functions for IRExpr need adjustment, too. ppIRExpr comes to mind and typeOfIRExpr. > I just had the unpleasant realisation that adding IRExprP__* has had an > undesired side effect: it is possible to put these constants at the leaf > of an expression tree, and get something which is completely meaningless, > eg IRExpr_Binop(Iop_Add64, IRExpr_RdTmp(t), IRExprP__BBPTR). Urr. True. And you can do similar nonsense with Iex_Binder expressions, btw. It might be better actually, to introduce new IRExpr node kinds for VECRET and BBPTR. Doing that makes it easier to find all the places that need adjustment. E.g. GCC has options to find unhandled enumerators in switch statements... And we would never have to worry about e->tag possibly segfaulting as long as e != 0. > In hindsight it would have been cleaner to have left IRExpr unchanged but > instead changed the type of the IRExprVec components to be a type which is > basically "all IRExpr*s, plus IRExprP__BBPTR, plus IRExpr__VECRET". Then > it wouldn't be possible to construct nonsense trees using the new constants. Yes. Florian |
|
From: Julian S. <js...@ac...> - 2013-08-14 08:31:51
|
On 08/13/2013 10:03 PM, Florian Krohm wrote: > I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, > the faulting address. Looks as if deepCopyIRExprVec does not handle the > special expressions introduced recently. I bet you are exactly right about that. Also shallowCopyIRExprVec has the same problem. deepCopyIRExprVec is only used by the IR loop unroller, which is relatively unlikely to be activated on code with dirty helper calls, which is why it didn't get detected until now. I just had the unpleasant realisation that adding IRExprP__* has had an undesired side effect: it is possible to put these constants at the leaf of an expression tree, and get something which is completely meaningless, eg IRExpr_Binop(Iop_Add64, IRExpr_RdTmp(t), IRExprP__BBPTR). Urr. In hindsight it would have been cleaner to have left IRExpr unchanged but instead changed the type of the IRExprVec components to be a type which is basically "all IRExpr*s, plus IRExprP__BBPTR, plus IRExpr__VECRET". Then it wouldn't be possible to construct nonsense trees using the new constants. J |