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
(9) |
|
2
(24) |
3
(22) |
4
(16) |
5
(32) |
6
(19) |
7
(22) |
8
(30) |
|
9
(21) |
10
(21) |
11
(20) |
12
(13) |
13
(24) |
14
(23) |
15
(13) |
|
16
(11) |
17
(6) |
18
(12) |
19
(17) |
20
(26) |
21
(25) |
22
(37) |
|
23
(32) |
24
(21) |
25
(30) |
26
(22) |
27
(24) |
28
(19) |
29
(9) |
|
30
(5) |
31
(6) |
|
|
|
|
|
|
From: Maynard J. <may...@us...> - 2011-10-31 20:01:04
|
On 10/31/2011 2:06 PM, Philippe Waroquiers wrote:
>
>> Actually, these tests run OK on F16, but fail on SLES 11 SP1. When running on
>> F16, the stdout and stderr output (both redirected to one file) show the
>> "hello world" and the "fun_set_me 1234" print outs. But I don't see either of
>> these when I run the same thing on SLES 11 SP1. I don't really know what to
>> look for to see where things go bad. I've attached both files in a tar file.
>> Thanks for your help!
>
> It looks like the inferior function call fails on S11 because gdb puts a break in
> a non-executable mapping of vgdb-test.
>
> On F16, to execute the function call, gdb puts a break at address 0x10000498,
> which is _start in vgdb-test.
> It then puts this address in the lr register, change the program counter to be
> the address of fun.
> And then everything works fine.
> --9441:1:aspacem ( 1) /home/mpj/vgdb-test
> ...
> --9441:1:aspacem 6: file 0010000000-001000ffff 65536 r-xT- d=0xfd01 i=406682 o=0
> (1)
> --9441:1:aspacem 7: file 0010010000-001001ffff 65536 rw--- d=0xfd01 i=406682 o=0
> (1)
>
> I tried the same test on the gcc farm PS3 ppc64/debian with gdb 7.3.1.
> It works similarly to the F16: it puts a break in _start (in the r-x mapped
> vgdb-test).
>
> On S11, gdb puts a break at address 0x10011010, which is also in vgdb-test.
> But it is in the "rw" mapping of vgdb-test, not the r-x mapping:
> --53993:1:aspacem ( 1) /home/mpj/temp/vgdb-test
> ...
> --53993:1:aspacem 4: file 0010000000-001000ffff 65536 r-x-- d=0xfd00 i=24314763
> o=0 (1)
> --53993:1:aspacem 5: file 0010010000-001001ffff 65536 rw--- d=0xfd00 i=24314763
> o=0 (1)
>
> I guess that the sig 11 is generated by Valgrind as it refuses to execute
> instruction in a non executable mapping.
>
> From what I can see by reading gdb code, gdb derives the _start address purely
> from the executable/debugging
> information, without querying gdbserver.
> So, it might be a bug in gdb, rather than a bug in the gdbserver.
> Which version of gdb are you using on S11 ?
> It might be worth trying with a recent gdb (e.g. the same as what I tried on the
> PS3 : gdb 7.3.1).
The version of stock gdb for SLES 11 SP1 is 7.0. I built valgrind and ran the
testcases using a newer toolchain, including a 7.3 gdb, and got different
(better?) results. Of the three failing testcases I mentioned earlier, one of
them passes, and two fail differently, but appear to be very minor failure
symptoms -- stderrB.diff has the following extra line:
+'import site' failed; use -v for traceback
Unfortunately, the gdbserver testsuite did not run to completion, since it hung
on the mcinvokeWS testcase. I just can't spend any more time on this now, but I
really appreciate your help in digging into these issues.
Thanks.
-Maynard
>
> If it still fails, the best will be to compare the behaviour between the gdb
> 7.3.1 gdbserver and
> the Valgrind gdbserver on S11 :
> * do the "break + fun call" with gdb 7.3.1 + Valgrind, using -v -v -v -d -d -d
> to have full trace.
> * do the same with the gdb 7.3.1 gdbserver+trace, something like:
> gdbserver --debug --remote-debug :1234 vgdb-test
> in another window:
> gdb vgdb-test
> target remote :1234
> ... same as with Valgrind : break then continue then p fun(1234)
>
> This should allow to confirm my reading of the gdb code regarding getting the
> _start address.
>
> Let's hope this is a gdb bug, otherwise finding why gdb + Valgrind gdbserver
> can't agree on the address
> of _start will not be a piece of cake.
> Philippe
>
> NB: what about the main_pic on F16. Is this more clear ?
>
|
|
From: Philippe W. <phi...@sk...> - 2011-10-31 19:06:25
|
> Actually, these tests run OK on F16, but fail on SLES 11 SP1. When running on > F16, the stdout and stderr output (both redirected to one file) show the "hello > world" and the "fun_set_me 1234" print outs. But I don't see either of these > when I run the same thing on SLES 11 SP1. I don't really know what to look for > to see where things go bad. I've attached both files in a tar file. Thanks for > your help! It looks like the inferior function call fails on S11 because gdb puts a break in a non-executable mapping of vgdb-test. On F16, to execute the function call, gdb puts a break at address 0x10000498, which is _start in vgdb-test. It then puts this address in the lr register, change the program counter to be the address of fun. And then everything works fine. --9441:1:aspacem ( 1) /home/mpj/vgdb-test ... --9441:1:aspacem 6: file 0010000000-001000ffff 65536 r-xT- d=0xfd01 i=406682 o=0 (1) --9441:1:aspacem 7: file 0010010000-001001ffff 65536 rw--- d=0xfd01 i=406682 o=0 (1) I tried the same test on the gcc farm PS3 ppc64/debian with gdb 7.3.1. It works similarly to the F16: it puts a break in _start (in the r-x mapped vgdb-test). On S11, gdb puts a break at address 0x10011010, which is also in vgdb-test. But it is in the "rw" mapping of vgdb-test, not the r-x mapping: --53993:1:aspacem ( 1) /home/mpj/temp/vgdb-test ... --53993:1:aspacem 4: file 0010000000-001000ffff 65536 r-x-- d=0xfd00 i=24314763 o=0 (1) --53993:1:aspacem 5: file 0010010000-001001ffff 65536 rw--- d=0xfd00 i=24314763 o=0 (1) I guess that the sig 11 is generated by Valgrind as it refuses to execute instruction in a non executable mapping. >From what I can see by reading gdb code, gdb derives the _start address purely from the executable/debugging information, without querying gdbserver. So, it might be a bug in gdb, rather than a bug in the gdbserver. Which version of gdb are you using on S11 ? It might be worth trying with a recent gdb (e.g. the same as what I tried on the PS3 : gdb 7.3.1). If it still fails, the best will be to compare the behaviour between the gdb 7.3.1 gdbserver and the Valgrind gdbserver on S11 : * do the "break + fun call" with gdb 7.3.1 + Valgrind, using -v -v -v -d -d -d to have full trace. * do the same with the gdb 7.3.1 gdbserver+trace, something like: gdbserver --debug --remote-debug :1234 vgdb-test in another window: gdb vgdb-test target remote :1234 ... same as with Valgrind : break then continue then p fun(1234) This should allow to confirm my reading of the gdb code regarding getting the _start address. Let's hope this is a gdb bug, otherwise finding why gdb + Valgrind gdbserver can't agree on the address of _start will not be a piece of cake. Philippe NB: what about the main_pic on F16. Is this more clear ? |
|
From: Maynard J. <may...@us...> - 2011-10-31 15:34:01
|
On 10/28/2011 6:01 PM, Philippe Waroquiers wrote:
>
>> Back on the SLES 11 SP1/POWER7 system, a fresh pull of upstream valgrind ran
>> quite well this time -- no hangs in the gdbserver tests,
>> and I still get the same three testcases failing: mcbreak, mcinfcallRU, and
>> mcinfcallWSRU. Again, the *.out files you asked for are attached.
>
> In the 'no extra options' file, we see that mcbreak fails when gdb invokes a
> function call.
> A break is encountered in t.c at line 112.
> The test executes a few "steps" and a "next"
> and then invokes a call to whoami("first").
> We see in mcbreak.stderr.out.unfiltered.out that the process crashes due to the
> following error:
> ==63162== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==63162== Bad permissions for mapped region at address 0x10012030
> ==63162== at 0x10000BB0: whoami (t.c:28)
> ==63162== by 0x10001183: main (t.c:112)
> The two other tests are also failing with a similar 'Bad permissions'. The
> address however slightly changes.
>
>
> If we examine more in details mcbreak.stderr.out.unfiltered.out (searching for
> signal 11),
> we see some lines above the following:
> --63758:1:gdbsrv stop_pc 0x10001194 changed to be resume_pc 0x401F4D0: malloc
> (dl-minimal.c:96)
>
> gdbsrv indicates that gdb has asked to change the pc at which the process was
> stopped (somewhere around t.c:112)
> to be another pc (the pc of malloc). This is because gdb must allocate memory in
> order to execute the whoami("first") :
> it first has to allocate memory by "pushing" a call to malloc.
> gdb has then to copy "first" in this memory, and it can then pushes a call to
> whoami.
>
> The usual technique with which gdb pushes a call is:
> It puts a break instruction somewhere (gdb has some logic depending on the OS
> and/or processor to find a "reasonable" place
> where such a break can be put).
> It then pushes the address where this break has been put as a return address
> (the technique to put the return address
> depends on the ABI. IIRC, on power, this is via a register)
> It puts the needed arguments
> and then invokes the function to call (e.g. malloc, or whoami, or ...) by
> changing the pc to be the pc of this function.
> When this function returns, it returns to the break instruction. The break
> causes gdb to regain control.
> gdb then knows the function call is finished. It recuperates the return value
> (e.g. what malloc has returned)
> and can continue.
>
> From what I can see, gdb uses the address 0x10012030 to put the break.
> It then calls malloc. But this malloc calls already fails (gives a signal 11).
> It looks like gdb believes the call has worked
> properly, as it then pushes a call to whoami.
>
> I do not know why the calls to malloc fails, and why the subsequent calls to
> whoami similarly fails.
>
> What could be done to investigate is to make a simpler test of invoking a
> function call.
> For example (not compiled):
> #include <stdio.h>
> int fun_set_me = 0;
> void fun (int i)
> {
> fun_set_me = i;
> }
> main()
> {
> printf ("hello world\n");
> printf ("fun_set_me %d\n", fun_set_me); <<< put a break here, then when
> encountered, call fun(1234) from gdb
> }
>
> Execute the above test on a f16/power7 valgrind with -v -v -v -d -d -d and gdb
> Do the same on suse.
> The difference in the trace between the two runs might explain what goes wrong
> on f16.
Actually, these tests run OK on F16, but fail on SLES 11 SP1. When running on
F16, the stdout and stderr output (both redirected to one file) show the "hello
world" and the "fun_set_me 1234" print outs. But I don't see either of these
when I run the same thing on SLES 11 SP1. I don't really know what to look for
to see where things go bad. I've attached both files in a tar file. Thanks for
your help!
-Maynard
>
> You might also compare the behaviour of the standard f16 gdbserver to the
> Valgrind gdbserver:
> The standard gdbserver has two options --debug and --remote-debug that will show
> the trace.
> This might also allow to compare a working function call invocation to the
> failing one under valgrind.
> The gdbserver protocol is relatively simple : the query packets and reply
> packets are explained in
> annex D of the gdb user manual. Note however that there will not be a one to one
> mapping between
> the packets exchange. E.g. gdb might send "Z" packets to insert "hardware
> breakpoints" to the
> Valgrind gdbserver (as valgrind gdbserver pretends it can implement hw
> watchpoint), and the standard
> gdbserver might indicate it only accepts breakpoints via chaning the instruction
> to a trap.
> But it should be possible to recognise the "push a call sequence".
>
> Hope the above helps ...
>
> Philippe
>
|
|
From: <sv...@va...> - 2011-10-31 15:30:44
|
Author: sewardj
Date: 2011-10-31 15:25:55 +0000 (Mon, 31 Oct 2011)
New Revision: 2230
Log:
Update comment in r2229 to place the blame in the right place.
Modified:
trunk/priv/guest_x86_helpers.c
Modified: trunk/priv/guest_x86_helpers.c
===================================================================
--- trunk/priv/guest_x86_helpers.c 2011-10-31 10:52:21 UTC (rev 2229)
+++ trunk/priv/guest_x86_helpers.c 2011-10-31 15:25:55 UTC (rev 2230)
@@ -1788,13 +1788,14 @@
/* Copy the x87 registers out of the image, into a temporary
Fpu_State struct. */
- /* Defeat LLVM's memset-idiom recognition mechanism. It
- appears to turn this into a misaligned movaps, which faults.
- This is with Xcode 4.1 (Build version 4B110), on x86-darwin,
- i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1
- (Based on Apple Inc. build 5658) (LLVM build 2335.15.00),
- OSX 10.7.1.
- */
+ /* LLVM on Darwin turns the following loop into a movaps plus a
+ handful of scalar stores. This would work fine except for the
+ fact that VEX doesn't keep the stack correctly (16-) aligned for
+ the call, so it segfaults. Hence, split the loop into two
+ pieces (and pray LLVM doesn't merely glue them back together) so
+ it's composed only of scalar stores and so is alignment
+ insensitive. Of course this is a kludge of the lamest kind --
+ VEX should be fixed properly. */
/* Code that seems to trigger the problem:
for (i = 0; i < 14; i++) tmp.env[i] = 0; */
for (i = 0; i < 7; i++) tmp.env[i+0] = 0;
|
|
From: <sv...@va...> - 2011-10-31 11:04:15
|
Author: sewardj
Date: 2011-10-31 10:59:31 +0000 (Mon, 31 Oct 2011)
New Revision: 12254
Log:
Use normal setjmp/longjmp, not the __builtin_ ones, as LLVM pretty
much treats the latter kind as no-ops.
Modified:
trunk/memcheck/tests/badjump2.c
Modified: trunk/memcheck/tests/badjump2.c
===================================================================
--- trunk/memcheck/tests/badjump2.c 2011-10-29 04:02:34 UTC (rev 12253)
+++ trunk/memcheck/tests/badjump2.c 2011-10-31 10:59:31 UTC (rev 12254)
@@ -13,7 +13,7 @@
static
void SIGSEGV_handler(int signum)
{
- __builtin_longjmp(myjmpbuf, 1);
+ longjmp(myjmpbuf, 1);
}
int main(void)
@@ -33,7 +33,7 @@
res = sigaction( SIGSEGV, &sigsegv_new, &sigsegv_saved );
assert(res == 0);
- if (__builtin_setjmp(myjmpbuf) == 0) {
+ if (setjmp(myjmpbuf) == 0) {
// Jump to zero; will cause seg fault
#if defined(__powerpc64__)
unsigned long int fn[3];
|
|
From: <sv...@va...> - 2011-10-31 10:57:05
|
Author: sewardj
Date: 2011-10-31 10:52:21 +0000 (Mon, 31 Oct 2011)
New Revision: 2229
Log:
x86g_dirtyhelper_FXRSTOR: work around what looks like a LLVM bug,
that causes this routine to segfault on x86-darwin.
Modified:
trunk/priv/guest_x86_helpers.c
Modified: trunk/priv/guest_x86_helpers.c
===================================================================
--- trunk/priv/guest_x86_helpers.c 2011-10-27 10:58:38 UTC (rev 2228)
+++ trunk/priv/guest_x86_helpers.c 2011-10-31 10:52:21 UTC (rev 2229)
@@ -1787,7 +1787,19 @@
/* Copy the x87 registers out of the image, into a temporary
Fpu_State struct. */
- for (i = 0; i < 14; i++) tmp.env[i] = 0;
+
+ /* Defeat LLVM's memset-idiom recognition mechanism. It
+ appears to turn this into a misaligned movaps, which faults.
+ This is with Xcode 4.1 (Build version 4B110), on x86-darwin,
+ i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1
+ (Based on Apple Inc. build 5658) (LLVM build 2335.15.00),
+ OSX 10.7.1.
+ */
+ /* Code that seems to trigger the problem:
+ for (i = 0; i < 14; i++) tmp.env[i] = 0; */
+ for (i = 0; i < 7; i++) tmp.env[i+0] = 0;
+ for (i = 0; i < 7; i++) tmp.env[i+7] = 0;
+
for (i = 0; i < 80; i++) tmp.reg[i] = 0;
/* fill in tmp.reg[0..7] */
for (stno = 0; stno < 8; stno++) {
|