This is the mail archive of the
mailing list for the elfutils project.
Re: [commit] [tests patchv2] FYI unwinder: tests/ update
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Thu, 05 Dec 2013 11:26:13 +0100
- Subject: Re: [commit] [tests patchv2] FYI unwinder: tests/ update
On Mon, 2013-12-02 at 21:42 +0100, Jan Kratochvil wrote:
> On Mon, 02 Dec 2013 20:40:38 +0100, Mark Wielaard wrote:
> > On Mon, 2013-12-02 at 20:16 +0100, Jan Kratochvil wrote:
> > > IIUC the tests/ patch is approved now?
> > Yes.
> Checked in: 8ae9bc9d315be6ecbb97dd9754b9d8424b5a70f0
I have one consistent failure in run-backtrace-native-core.sh (but
run-backtrace-native-core-biarch.sh works fine) on both my x86_64
setups. The setups are very different. One has kernel 2.6.32, gcc 4.4.7
and glibc 2.12, the other kernel 3.11.8, gcc 4.8.2 and glibc-2.18.
The backtrace generated is:
#0 0x00007fd3a47975db raise
#1 0x00007fd3a4bc7dec stdarg
#2 0x00007fd3a4bc7e70 backtracegen
#3 0x00007fd3a4bc7e79 start
#4 0x00007fd3a478f9d1 start_thread
#5 0x00007fd3a44dcb6d __clone
It might not be our unwinder, since gdb produces the same:
#0 0x00007fd3a47975db in raise (sig=6)
#1 0x00007fd3a4bc7dec in stdarg (f=<value optimized out>)
#2 0x00007fd3a4bc7e70 in backtracegen ()
#3 0x00007fd3a4bc7e79 in start (arg=<value optimized out>)
#4 0x00007fd3a478f9d1 in start_thread (arg=0x7fd3a43f3700)
#5 0x00007fd3a44dcb6d in clone ()
Note that the backtrace looks as if the SIGABRT is actually being
generated from the first signal handler that raises SIGUSR2.
It can be worked around by adding an extra statement after the raise
(SIGABRT) in siguser2:
diff --git a/tests/backtrace-child.c b/tests/backtrace-child.c
index 2bc0ede..528e315 100644
@@ -105,6 +105,7 @@ sigusr2 (int signo)
/* Here we dump the core for --gencore. */
+ printf ("Never reached...\n");
static NOINLINE_NOCLONE void
Then the test passes on both setups. And the backtrace also looks as
expected in gdb.
I have not yet looked much deeper into this. Given that gdb also gets a
weird backtrace I am somewhat inclined to go with the workaround for
now. But it definitely needs at least a better analysis. Do you have a
setup where this test passes without the extra workaround? I have
uploaded the generated executable and core file (without the workaround)