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
(3) |
3
(2) |
4
(1) |
5
(1) |
6
(6) |
7
(9) |
|
8
(8) |
9
(6) |
10
(13) |
11
(9) |
12
(12) |
13
(6) |
14
(1) |
|
15
(4) |
16
(8) |
17
(15) |
18
(7) |
19
(3) |
20
(11) |
21
(7) |
|
22
(26) |
23
(7) |
24
(4) |
25
(9) |
26
(10) |
27
(13) |
28
(6) |
|
29
(11) |
30
(6) |
31
(8) |
|
|
|
|
|
From: Todd J. <qua...@gm...> - 2010-08-24 17:00:22
|
On Aug 24, 2010, at 12:42 AM, Tom Hughes wrote: > On 24/08/10 07:19, Todd Jackson wrote: > >> Backround: I have test programs that contain instructions that shift the stack pointer between 4 and 6 MB down (eg. leal $-4243104(%esp), %esp) at the beginning of the program. This causes Valgrind to receive a signal 11, manipulate the stack, and then restart the instruction that caused the signal. Valgrind tells me that it thinks that the client has switched stacks and to use --max-stackframe=6291452. I have tried --main-stacksize and the given --max-stackframe option to suppress the signal to no avail. Valgrind runs fine - I just want to avoid this signal 11. From the comments in Valgrind it seems like the signal is caused by the program exceeding some kind of stack limit, but I'm not sure where. > > Why do you want to stop the signal 11 though? It's entirely normal and is how the stack gets extended in all programs. > > The only difference is that normally the fault is handled by the kernel, which extends the stack and restarts the program, and here valgrind is acting as the supervisor and catching the fault and performing the stack extension. > Valgrind is running under a process monitor. The monitor is getting confused by the signal 11, because the monitor watches at least two versions (same source code, different binary) the same program at the same time to make sure they're doing the same thing. I see the signal 11 in one version and not the other, which is why I want to prevent the signal 11. I think I can get around it by rearranging the guest's stack pointer at start up so that the shift doesn't cause the signal 11 and subsequent stack extension, but I can't find the stack initialization code in Valgrind. Todd |
|
From: <sv...@va...> - 2010-08-24 09:06:04
|
Author: sewardj
Date: 2010-08-24 10:05:52 +0100 (Tue, 24 Aug 2010)
New Revision: 11288
Log:
Change the replacement for memcpy to a vectorised version that does
word copies whenever possible. This drastically reduces the number of
memory references Memcheck has to process and speeds up a test program
that does repeated memcpys of large blocks by a factor of 4 or more.
Also add a vectorised version of memset.
The memcpy version is also constructed with a view to be used in
exp-ptrcheck, so it can copy areas of memory without losing
pointer-identity shadow data, as happens when doing all copies at a
byte granularity.
Modified:
trunk/memcheck/mc_replace_strmem.c
Modified: trunk/memcheck/mc_replace_strmem.c
===================================================================
--- trunk/memcheck/mc_replace_strmem.c 2010-08-22 22:18:31 UTC (rev 11287)
+++ trunk/memcheck/mc_replace_strmem.c 2010-08-24 09:05:52 UTC (rev 11288)
@@ -455,42 +455,68 @@
void* VG_REPLACE_FUNCTION_ZU(soname,fnname) \
( void *dst, const void *src, SizeT len ) \
{ \
- register char *d; \
- register char *s; \
- \
- if (len == 0) \
- return dst; \
- \
if (is_overlap(dst, src, len, len)) \
RECORD_OVERLAP_ERROR("memcpy", dst, src, len); \
\
- if ( dst > src ) { \
- d = (char *)dst + len - 1; \
- s = (char *)src + len - 1; \
- while ( len >= 4 ) { \
- *d-- = *s--; \
- *d-- = *s--; \
- *d-- = *s--; \
- *d-- = *s--; \
- len -= 4; \
+ const Addr WS = sizeof(UWord); /* 8 or 4 */ \
+ const Addr WM = WS - 1; /* 7 or 3 */ \
+ \
+ if (dst < src) { \
+ \
+ /* Copying backwards. */ \
+ SizeT n = len; \
+ Addr d = (Addr)dst; \
+ Addr s = (Addr)src; \
+ \
+ if (((s^d) & WM) == 0) { \
+ /* s and d have same UWord alignment. */ \
+ /* Pull up to a UWord boundary. */ \
+ while ((s & WM) != 0 && n >= 1) \
+ { *(UChar*)d = *(UChar*)s; s += 1; d += 1; n -= 1; } \
+ /* Copy UWords. */ \
+ while (n >= WS) \
+ { *(UWord*)d = *(UWord*)s; s += WS; d += WS; n -= WS; } \
+ if (n == 0) \
+ return dst; \
} \
- while ( len-- ) { \
- *d-- = *s--; \
+ if (((s|d) & 1) == 0) { \
+ /* Both are 16-aligned; copy what we can thusly. */ \
+ while (n >= 2) \
+ { *(UShort*)d = *(UShort*)s; s += 2; d += 2; n -= 2; } \
} \
- } else if ( dst < src ) { \
- d = (char *)dst; \
- s = (char *)src; \
- while ( len >= 4 ) { \
- *d++ = *s++; \
- *d++ = *s++; \
- *d++ = *s++; \
- *d++ = *s++; \
- len -= 4; \
+ /* Copy leftovers, or everything if misaligned. */ \
+ while (n >= 1) \
+ { *(UChar*)d = *(UChar*)s; s += 1; d += 1; n -= 1; } \
+ \
+ } else if (dst > src) { \
+ \
+ SizeT n = len; \
+ Addr d = ((Addr)dst) + n; \
+ Addr s = ((Addr)src) + n; \
+ \
+ /* Copying forwards. */ \
+ if (((s^d) & WM) == 0) { \
+ /* s and d have same UWord alignment. */ \
+ /* Back down to a UWord boundary. */ \
+ while ((s & WM) != 0 && n >= 1) \
+ { s -= 1; d -= 1; *(UChar*)d = *(UChar*)s; n -= 1; } \
+ /* Copy UWords. */ \
+ while (n >= WS) \
+ { s -= WS; d -= WS; *(UWord*)d = *(UWord*)s; n -= WS; } \
+ if (n == 0) \
+ return dst; \
} \
- while ( len-- ) { \
- *d++ = *s++; \
+ if (((s|d) & 1) == 0) { \
+ /* Both are 16-aligned; copy what we can thusly. */ \
+ while (n >= 2) \
+ { s -= 2; d -= 2; *(UShort*)d = *(UShort*)s; n -= 2; } \
} \
+ /* Copy leftovers, or everything if misaligned. */ \
+ while (n >= 1) \
+ { s -= 1; d -= 1; *(UChar*)d = *(UChar*)s; n -= 1; } \
+ \
} \
+ \
return dst; \
}
@@ -584,18 +610,16 @@
void* VG_REPLACE_FUNCTION_ZU(soname,fnname)(void *s, Int c, SizeT n); \
void* VG_REPLACE_FUNCTION_ZU(soname,fnname)(void *s, Int c, SizeT n) \
{ \
- unsigned char *cp = s; \
- while (n >= 4) { \
- cp[0] = c; \
- cp[1] = c; \
- cp[2] = c; \
- cp[3] = c; \
- cp += 4; \
- n -= 4; \
- } \
- while (n--) { \
- *cp++ = c; \
- } \
+ Addr a = (Addr)s; \
+ UInt c4 = (c & 0xFF); \
+ c4 = (c4 << 8) | c4; \
+ c4 = (c4 << 16) | c4; \
+ while ((a & 3) != 0 && n >= 1) \
+ { *(UChar*)a = (UChar)c; a += 1; n -= 1; } \
+ while (n >= 4) \
+ { *(UInt*)a = c4; a += 4; n -= 4; } \
+ while (n >= 1) \
+ { *(UChar*)a = (UChar)c; a += 1; n -= 1; } \
return s; \
}
|
|
From: Tom H. <to...@co...> - 2010-08-24 07:42:59
|
On 24/08/10 07:19, Todd Jackson wrote: > Backround: I have test programs that contain instructions that shift the stack pointer between 4 and 6 MB down (eg. leal $-4243104(%esp), %esp) at the beginning of the program. This causes Valgrind to receive a signal 11, manipulate the stack, and then restart the instruction that caused the signal. Valgrind tells me that it thinks that the client has switched stacks and to use --max-stackframe=6291452. I have tried --main-stacksize and the given --max-stackframe option to suppress the signal to no avail. Valgrind runs fine - I just want to avoid this signal 11. From the comments in Valgrind it seems like the signal is caused by the program exceeding some kind of stack limit, but I'm not sure where. Why do you want to stop the signal 11 though? It's entirely normal and is how the stack gets extended in all programs. The only difference is that normally the fault is handled by the kernel, which extends the stack and restarts the program, and here valgrind is acting as the supervisor and catching the fault and performing the stack extension. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Todd J. <qua...@gm...> - 2010-08-24 06:19:46
|
Hello all, I'm working on my own tool for Valgrind and have a few questions on how it handles stack movement: Backround: I have test programs that contain instructions that shift the stack pointer between 4 and 6 MB down (eg. leal $-4243104(%esp), %esp) at the beginning of the program. This causes Valgrind to receive a signal 11, manipulate the stack, and then restart the instruction that caused the signal. Valgrind tells me that it thinks that the client has switched stacks and to use --max-stackframe=6291452. I have tried --main-stacksize and the given --max-stackframe option to suppress the signal to no avail. Valgrind runs fine - I just want to avoid this signal 11. From the comments in Valgrind it seems like the signal is caused by the program exceeding some kind of stack limit, but I'm not sure where. The test programs work find outside of Valgrind. Questions: Is there a better way of preventing this signal 11 from the command line? Where in Valgrind does it set the stack that the client program uses and the memory block that sets up the client's stack? Thanks! |