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
(6) |
2
(10) |
3
(4) |
|
4
|
5
|
6
|
7
|
8
|
9
(2) |
10
|
|
11
|
12
(6) |
13
(5) |
14
(2) |
15
(4) |
16
(3) |
17
(1) |
|
18
|
19
(1) |
20
(6) |
21
(4) |
22
|
23
|
24
(2) |
|
25
|
26
(4) |
27
(10) |
28
(12) |
29
(29) |
30
(6) |
|
|
From: Adarsh Y. <ay...@um...> - 2010-04-27 21:57:41
|
Hi,
I am trying to create the tool for predicting return address in Valgrind.
All I am doing now is just adding temporary code to the cachegrind tool to
recognize function calls and return events and act accordingly.
The changes are very minimal. But when i run it I am getting an error which
says that the "Impossible happened!!" and the VEX temporary storage has been
exhausted.
Could someone let me know if you have any idea what this error is about and
maybe some pointers on how to go about solving it.
The error being reported:
VEX temporary storage exhausted.
Pool = TEMP, start 0x383353d0 curr 0x386f542c end 0x38705ccf (size 4000000)
vex: the `impossible' happened:
VEX temporary storage exhausted.
Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
vex storage: T total 526792 bytes allocated
vex storage: P total 288 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==18961== at 0x3800A3C5: report_and_quit (m_libcassert.c:191)
==18961== by 0x3800A42B: panic (m_libcassert.c:275)
==18961== by 0x3800A47D: vgPlain_core_panic_at (m_libcassert.c:280)
==18961== by 0x3800A498: vgPlain_core_panic (m_libcassert.c:285)
==18961== by 0x380235E6: failure_exit (m_translate.c:674)
==18961== by 0x380A87DE: vpanic (main_util.c:237)
==18961== by 0x380A8EE0: private_LibVEX_alloc_OOM (main_util.c:182)
==18961== by 0x380ACFAD: addStmtToIRSB (libvex.h:310)
==18961== by 0x38001394: flushEvents (cg_main.c:828)
==18961== by 0x38001E38: cg_instrument (cg_main.c:1236)
==18961== by 0x380A704B: LibVEX_Translate (main_main.c:528)
==18961== by 0x38021055: vgPlain_translate (m_translate.c:1518)
==18961== by 0x38047FE8: vgPlain_scheduler (scheduler.c:857)
==18961== by 0x38072F98: run_a_thread_NORETURN (syswrap-linux.c:94)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==18961== at 0xB1B357: _dl_start (in /lib/ld-2.5.so)
==18961== by 0xB1A816: ??? (in /lib/ld-2.5.so)
--
Adarsh Yoga
Graduate Student, Computer Science
Indiana University, Bloomington
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-27 17:27:05
|
In case you are curious: with PIN we rely on the fact that SBs are acyclic and it helps a lot. I've described the details here: http://code.google.com/p/data-race-test/wiki/ThreadSanitizerAlgorithm#Instrumentation:_TRACEs --kcc On Tue, Apr 27, 2010 at 8:38 PM, Konstantin Serebryany <kon...@gm...> wrote: > On Tue, Apr 27, 2010 at 7:46 PM, Julian Seward <js...@ac...> wrote: >> On Tuesday 27 April 2010, Konstantin Serebryany wrote: >>> Below is a dump of IRSB. >>> Just look at these statements: >>> ------ IMark(0x4C1C3A4, 4) ------ >>> ... >>> if (t20) goto {Boring} 0x4C1C3B4:I64 >>> goto {Boring} 0x4C1C3A4:I64 >>> >>> As you can see, this IRSB represents a loop (label 0x4C1C3A4). >> >> Yes. >> >>> I want valgrind to never create such IRSBs with a loop (but instead break >>> them into several SBs). >>> Is that possible? >> >> Uh .. I'm still confused. Mostly because I can't see how you can >> guarantee to avoid making IRSBs which have a conditional branch >> back to the start. For example, consider the translation of >> "rep movsb"; we have to create a straight line block of IR which >> jumps back to the start. >> >> Can you show an IR example which illustrates what you mean? >> eg, what does the IR that you want look like, for this example? > > > Consider an SB which looks like this: > > BB1: > L: > code; > goto L; > > Can valgrind create two SBs for this case? > BB1: > L: > code; > goto L1 > > BB2: > L1: > goto L > > > --kcc > >> >> J >> > |
|
From: Konstantin S. <kon...@gm...> - 2010-04-27 16:39:06
|
On Tue, Apr 27, 2010 at 7:46 PM, Julian Seward <js...@ac...> wrote:
> On Tuesday 27 April 2010, Konstantin Serebryany wrote:
>> Below is a dump of IRSB.
>> Just look at these statements:
>> ------ IMark(0x4C1C3A4, 4) ------
>> ...
>> if (t20) goto {Boring} 0x4C1C3B4:I64
>> goto {Boring} 0x4C1C3A4:I64
>>
>> As you can see, this IRSB represents a loop (label 0x4C1C3A4).
>
> Yes.
>
>> I want valgrind to never create such IRSBs with a loop (but instead break
>> them into several SBs).
>> Is that possible?
>
> Uh .. I'm still confused. Mostly because I can't see how you can
> guarantee to avoid making IRSBs which have a conditional branch
> back to the start. For example, consider the translation of
> "rep movsb"; we have to create a straight line block of IR which
> jumps back to the start.
>
> Can you show an IR example which illustrates what you mean?
> eg, what does the IR that you want look like, for this example?
Consider an SB which looks like this:
BB1:
L:
code;
goto L;
Can valgrind create two SBs for this case?
BB1:
L:
code;
goto L1
BB2:
L1:
goto L
--kcc
>
> J
>
|
|
From: Julian S. <js...@ac...> - 2010-04-27 15:30:22
|
On Tuesday 27 April 2010, Konstantin Serebryany wrote:
> Below is a dump of IRSB.
> Just look at these statements:
> ------ IMark(0x4C1C3A4, 4) ------
> ...
> if (t20) goto {Boring} 0x4C1C3B4:I64
> goto {Boring} 0x4C1C3A4:I64
>
> As you can see, this IRSB represents a loop (label 0x4C1C3A4).
Yes.
> I want valgrind to never create such IRSBs with a loop (but instead break
> them into several SBs).
> Is that possible?
Uh .. I'm still confused. Mostly because I can't see how you can
guarantee to avoid making IRSBs which have a conditional branch
back to the start. For example, consider the translation of
"rep movsb"; we have to create a straight line block of IR which
jumps back to the start.
Can you show an IR example which illustrates what you mean?
eg, what does the IR that you want look like, for this example?
J
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-27 15:13:21
|
Below is a dump of IRSB.
Just look at these statements:
------ IMark(0x4C1C3A4, 4) ------
...
if (t20) goto {Boring} 0x4C1C3B4:I64
goto {Boring} 0x4C1C3A4:I64
As you can see, this IRSB represents a loop (label 0x4C1C3A4).
I want valgrind to never create such IRSBs with a loop (but instead break
them into several SBs).
Is that possible?
--kcc
IRSB {
t0:I64 t1:I64 t2:I64 t3:I64 t4:I64 t5:I64 t6:I64 t7:I64
t8:I64 t9:I64 t10:I64 t11:I64 t12:I64 t13:I32 t14:I8
t15:I64
t16:I64 t17:I64 t18:I64 t19:I8 t20:I1 t21:I64 t22:I64
t23:I64
t24:I64 t25:I64 t26:I32 t27:I64 t28:I64 t29:I1 t30:I1
------ IMark(0x4C1C3A4, 4) ------
t10 = GET:I64(8)
t11 = GET:I64(48)
t8 = Add64(t11,t10)
t14 = LDle:I8(t8)
t26 = 8Uto32(t14)
t13 = t26
t27 = 32Uto64(t13)
t12 = t27
PUT(0) = t12
------ IMark(0x4C1C3A8, 3) ------
PUT(168) = 0x4C1C3A8:I64
t18 = GET:I64(56)
t15 = Add64(t18,t10)
t19 = GET:I8(0)
STle(t15) = t19
------ IMark(0x4C1C3AB, 4) ------
t2 = Add64(t10,0x1:I64)
PUT(8) = t2
------ IMark(0x4C1C3AF, 3) ------
t7 = GET:I64(16)
IR-NoOp
PUT(128) = 0x8:I64
PUT(136) = t7
PUT(144) = t2
------ IMark(0x4C1C3B2, 2) ------
PUT(168) = 0x4C1C3B2:I64
IR-NoOp
t29 = CmpLE64U(t7,t2)
t28 = 1Uto64(t29)
t25 = t28
t30 = 64to1(t25)
t20 = t30
if (t20) goto {Boring} 0x4C1C3B4:I64
goto {Boring} 0x4C1C3A4:I64
}
On Tue, Apr 27, 2010 at 5:03 PM, Julian Seward <js...@ac...> wrote:
>
> You can disable loop unrolling using --vex-iropt-unroll-thresh=0,
> and there is an equivalent way to do it programmatically -- I think
> callgrind disables unrolling at startup.
>
> But in any case I don't think I understand the question. If you want
> to know the maximal number of accesses from a given IRSB, just count
> them (by looking at all the IRStmts inside it). Loop unrolling or
> chasing across bb boundaries (it follows calls and jumps to unknown
> destinations by default) should not have any effect. An IRSB that
> is "unrolled" is not turned into a loop that runs "within the IRSB",
> it is just that the IRSB is made to contain 2, 4 or 8 copies of the
> loop body. You can still get an upper bound of the number of memory
> accesses just from instrumentation-time examination.
>
> Does that make sense? (Maybe I didn't understand your question right.)
>
> J
>
> On Wednesday 21 April 2010, Konstantin Serebryany wrote:
> > Hi,
> > Currently, IRSB may contain a loop (e.g. a loop from a memcpy-like
> function
> > will be translated into one IRSB).
> > Is there a way to force valgrind to create only acyclic IRSBs?
> >
> > Why: I am doing an optimization in ThreadSanitizer which requires to know
> > (during instrumentation) the maximal number of memory accesses in a given
> > IRSB.
> >
> > Thanks,
> >
> > --kcc
>
>
>
|
|
From: Rich C. <Ric...@me...> - 2010-04-27 13:14:27
|
Hi Julian, I stopped using the berkley db during svn trials using an early version of svn. I've sinced used fsfs type for all my svn repos and haven't had any issues. I think the bdb svn repo gets corrupted when an svn commit gets interrupted or canceled. It's a long known problem. Rich On Tue, 27 Apr 2010 13:44:32 +0200 Julian Seward <js...@ac...> wrote: > > Yes, something is not good w/ the repo. For some reason the svn > server created about 5GB of Berkeley DB log files and ran out of > space. Now the vex repo is corrupted, or at least, "svnadmin > hotcopy" is not happy, and no amount of "svnadmin recover" fixes it, > even though "svnadmin verify" says it's fine. > > So I am inclined to go back to the last vex repo backup and reland > r1968 through r1976. The other repos (valgrind, valgrind-www) appear > to be OK. > > J > > > On Monday 26 April 2010, Bart Van Assche wrote: > > Hello, > > > > Is there something wrong with the Valgrind repository ? I get the > > following error message since about three days when I try to access > > the Valgrind repository: > > > > $ svn ls svn://svn.valgrind.org/valgrind > > svn: Berkeley DB error for filesystem '/home/svn/repos/valgrind/db' > > while opening 'nodes' table: > > Cannot allocate memory > > svn: bdb: Lock table is out of available locker entries > > > > Bart. > > > > --------------------------------------------------------------------------- > >--- _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > -- |
|
From: Julian S. <js...@ac...> - 2010-04-27 12:48:10
|
You can disable loop unrolling using --vex-iropt-unroll-thresh=0, and there is an equivalent way to do it programmatically -- I think callgrind disables unrolling at startup. But in any case I don't think I understand the question. If you want to know the maximal number of accesses from a given IRSB, just count them (by looking at all the IRStmts inside it). Loop unrolling or chasing across bb boundaries (it follows calls and jumps to unknown destinations by default) should not have any effect. An IRSB that is "unrolled" is not turned into a loop that runs "within the IRSB", it is just that the IRSB is made to contain 2, 4 or 8 copies of the loop body. You can still get an upper bound of the number of memory accesses just from instrumentation-time examination. Does that make sense? (Maybe I didn't understand your question right.) J On Wednesday 21 April 2010, Konstantin Serebryany wrote: > Hi, > Currently, IRSB may contain a loop (e.g. a loop from a memcpy-like function > will be translated into one IRSB). > Is there a way to force valgrind to create only acyclic IRSBs? > > Why: I am doing an optimization in ThreadSanitizer which requires to know > (during instrumentation) the maximal number of memory accesses in a given > IRSB. > > Thanks, > > --kcc |
|
From: Julian S. <js...@ac...> - 2010-04-27 12:36:11
|
The svn server is running again now, but I will have to mess the vex repo more later today. J On Tuesday 27 April 2010, Julian Seward wrote: > Yes, something is not good w/ the repo. For some reason the svn > server created about 5GB of Berkeley DB log files and ran out of > space. Now the vex repo is corrupted, or at least, "svnadmin > hotcopy" is not happy, and no amount of "svnadmin recover" fixes it, > even though "svnadmin verify" says it's fine. > > So I am inclined to go back to the last vex repo backup and reland > r1968 through r1976. The other repos (valgrind, valgrind-www) appear > to be OK. > > J > > On Monday 26 April 2010, Bart Van Assche wrote: > > Hello, > > > > Is there something wrong with the Valgrind repository ? I get the > > following error message since about three days when I try to access > > the Valgrind repository: > > > > $ svn ls svn://svn.valgrind.org/valgrind > > svn: Berkeley DB error for filesystem '/home/svn/repos/valgrind/db' > > while opening 'nodes' table: > > Cannot allocate memory > > svn: bdb: Lock table is out of available locker entries > > > > Bart. > > > > ------------------------------------------------------------------------- > >-- --- _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > --------------------------------------------------------------------------- >--- _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Julian S. <js...@ac...> - 2010-04-27 11:28:42
|
Yes, something is not good w/ the repo. For some reason the svn server created about 5GB of Berkeley DB log files and ran out of space. Now the vex repo is corrupted, or at least, "svnadmin hotcopy" is not happy, and no amount of "svnadmin recover" fixes it, even though "svnadmin verify" says it's fine. So I am inclined to go back to the last vex repo backup and reland r1968 through r1976. The other repos (valgrind, valgrind-www) appear to be OK. J On Monday 26 April 2010, Bart Van Assche wrote: > Hello, > > Is there something wrong with the Valgrind repository ? I get the > following error message since about three days when I try to access > the Valgrind repository: > > $ svn ls svn://svn.valgrind.org/valgrind > svn: Berkeley DB error for filesystem '/home/svn/repos/valgrind/db' > while opening 'nodes' table: > Cannot allocate memory > svn: bdb: Lock table is out of available locker entries > > Bart. > > --------------------------------------------------------------------------- >--- _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Ali K. <akh...@in...> - 2010-04-27 04:30:28
|
ok, I guess here's what i'm not getting about SP
I've got the following code in the instrument function to retrieve the
stack pointer
-===========
type = layout->sizeof_SP == 8 ? Ity_I64 : Ity_I32;
IRExpr* ee = IRExpr_Get(layout->offset_SP,type);
IRTemp temp = newIRTemp (sbIn->tyenv, gWordTy);
addStmtToIRSB (sbIn,
IRStmt_WrTmp (temp,
IRExpr_Get (offsetof (VexGuestX86State,
guest_EIP),
gWordTy)));
Int spAddress = offsetof (VexGuestX86State,guest_ESP);
VG_(printf)("%d",spAddress); /* this value does not change */
VG_(printf)("%d",temp); /* this value changes a lot
*/
VG_(printf)("\n");
}
return sbOut;
============
problem is, i can't find any consistency, the first one (spAddress),
gives me the same value throughout the program (in each superblock)
the second one (temp) gives me totally different values everytime,
though I can't believe the stack pointer changes with that frequency
is there anything I'm missing here?
my approach is that I'm trying to get the stack pointer, if it changes
that would mean either a function is called or a return is occuring
(that's my logic anyway)
-------- Original Message --------
Subject: Re: [Valgrind-developers] Return predictor
From: Alexander Potapenko <gl...@go...>
To: Ali Khalfan <akh...@in...>
Cc: val...@li...
Date: Mon Apr 26 2010 05:21:09 GMT-0400 (EDT)
> It's possible to handle the changes of SP, although sometimes a
> call-return pair may not change SP.
>
> You may want to look at how it's done in ThreadSanitizer
> (http://code.google.com/p/data-race-test/), see
> http://code.google.com/p/data-race-test/source/browse/trunk/tsan/ts_valgrind.cc
> ThreadSanitizer keeps the shadow stack to speed up unwinding.
>
> Alex
>
> On Sat, Apr 24, 2010 at 7:31 AM, Ali Khalfan <akh...@in...> wrote:
>
>> Hi,
>>
>> I'm trying to develop a tool that would predict return addresses. So I
>> intend to store a function call address in a buffer once a call takes
>> places and then remove it from the buffer once the return happens.
>>
>>
>> Is there a way I could get the return instructions using valgrind? I've
>> been looking at the lackey examples and see that that jumps can be
>> processed,
>>
>> so is there a way to get just the return statements?
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Valgrind-developers mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>>
>>
>
>
>
>
|