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
|
3
|
|
4
(2) |
5
|
6
|
7
(2) |
8
(2) |
9
(6) |
10
(1) |
|
11
(2) |
12
|
13
(3) |
14
|
15
(3) |
16
(1) |
17
|
|
18
(6) |
19
|
20
|
21
(2) |
22
|
23
|
24
|
|
25
|
26
|
27
|
28
(1) |
29
(2) |
30
|
31
|
|
From: Carl L. <ce...@us...> - 2018-03-15 19:14:46
|
Julian:
Setting --vex-guest-max-insns=1 gets us past the assertion. We then
hit an error that Valgrind tried to execute an illegal instruction. My
initial inspection looks like a move instruction to and SPR. I suspect
we have another SPR that is not supported. This is a power specific
issue which I will work on.
Thanks for the help.
Carl Love
On Thu, 2018-03-15 at 19:38 +0100, Julian Seward wrote:
> Carl,
>
> > I have printed the values used to do the UNLIKELY check, they are:
> > out_used = 60000, j = 8, vta->host_bytes_size = 60000
> > #define N_TMPBUF 60000
> >
> > There is a check on the size in m_translate.c
> >
> > /* Copy data at trans_addr into the translation cache. */
> > vg_assert(tmpbuf_used > 0 && tmpbuf_used < 65536);
>
> Taking those 60000 values above 65535 isn't possible (without a great
> deal of hackery), because the translated code size is stored as an
> unsigned 16-bit int in various places. However ..
>
> > Is there another way to get coregrind to process the instructions
> > in smaller chunks to not over flow the buffer?
>
> Yes. By default it processes up to 50 (I think) insns in a block.
> You can reduce that down to 1, by using --vex-guest-max-
> insns=<number>.
>
> I would say though that overflowing the max translation size is
> symptomatic of the instrumentation being very verbose. If it is
> possible to generate more concise instrumentation IR, that would be a
> better longer term solution.
>
> J
>
|
|
From: Julian S. <js...@ac...> - 2018-03-15 18:38:23
|
Carl, > I have printed the values used to do the UNLIKELY check, they are: > out_used = 60000, j = 8, vta->host_bytes_size = 60000 > #define N_TMPBUF 60000 > > There is a check on the size in m_translate.c > > /* Copy data at trans_addr into the translation cache. */ > vg_assert(tmpbuf_used > 0 && tmpbuf_used < 65536); Taking those 60000 values above 65535 isn't possible (without a great deal of hackery), because the translated code size is stored as an unsigned 16-bit int in various places. However .. > Is there another way to get coregrind to process the instructions > in smaller chunks to not over flow the buffer? Yes. By default it processes up to 50 (I think) insns in a block. You can reduce that down to 1, by using --vex-guest-max-insns=<number>. I would say though that overflowing the max translation size is symptomatic of the instrumentation being very verbose. If it is possible to generate more concise instrumentation IR, that would be a better longer term solution. J |
|
From: Carl L. <ce...@us...> - 2018-03-15 17:55:06
|
Valgrind maintainers:
I am trying to help a user debug a failure that he is seeing. First of
all, he has written his own valgrind plug in to called memtemp. The
plugin is used to characterize the memory access pattern for a given
workload. Specifically, it instruments all of the Load and Store
operations. The plugin collects data about the size of the load/store,
from what memory it is loading etc.
The issue is with his plugin installed, we hit the assertion
/* Sheesh. Finally, actually _do_ the translation! */
tres = LibVEX_Translate ( &vta );
vg_assert(tres.status == VexTransOK);
in coregrind/m_translate.c. Tracking this back, we see that
tres.status was set in VEX/priv/main_main.c at
VEX/priv/main_main.c
if (UNLIKELY(out_used + j > vta->host_bytes_size)) {
vexSetAllocModeTEMP_and_clear();
vex_traceflags = 0;
res->status = VexTransOutputFull;
return;
}
I have printed the values used to do the UNLIKELY check, they are:
out_used = 60000, j = 8, vta->host_bytes_size = 60000
Note, out_used is updated each time through the loop. So basically it
looks like we have exceeded the size of vta->host_bytes_size.
Basically a few lines down from the check is where the entry from
insn_bytes[k] is assigned into vta->host_bytes[out_used].
So, I tried to track down host_bytes_size. I don't really know what
the use of this buffer is. It is declared in VEX/pub/libvex.h. It
appears to be initialized to size
coregrind/m_translate.c: vta.host_bytes_size = N_TMPBUF.
The value is set in coregrind/m_translate.c
#define N_TMPBUF 60000
There is a check on the size in m_translate.c
/* Copy data at trans_addr into the translation cache. */
vg_assert(tmpbuf_used > 0 && tmpbuf_used < 65536);
which is obviously hard wired.
So, it looks to me as if the instrumentation that memtemp adds must be
adding instructions to the code resulting in overflowing the size of
the translation cache?
Not sure how safe it would be to increase the size of N_TMPBUF would
be? Is there another way to get coregrind to process the instructions
in smaller chunks to not over flow the buffer?
Any thoughts on how to fix this issue would be appreciated. Thanks.
Carl Love
|