This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] libebl: Add ebl_unwind_ret_mask.

On Sun, Jun 15, 2014 at 08:56:17PM +0200, Mark Wielaard wrote:
> On Sun, 2014-06-15 at 20:47 +0200, Kurt Roeckx wrote:
> > On Sun, Jun 15, 2014 at 08:38:20PM +0200, Mark Wielaard wrote:
> > > 
> > > Since the sparc backend doesn't have unwinder support it sounds unlikely
> > > one of these patches triggered the bus error. Do you have more
> > > specifics? Which test triggers it, do you have a backtrace? Are there
> > > logs before/after, etc.
> > 
> > Log before:
> >
> > 
> > Log after:
> >
> Strange indeed. But I am afraid you'll have to run one of the failing
> tests under GDB to help debug it. At least so we know where it is
> crashing and if it is crashing in elfutils code or somewhere else (using
> completely different gcc and glibc versions before/after is slightly
> suspicious, even though it might still be a bug in our code of course).

Program terminated with signal SIGBUS, Bus error.
b#0  core_set_initial_registers (thread=0xffef2018, thread_arg_voidp=<optimized out>) at linux-core-attach.c:299
299                   uint64_t val64 = *(const uint64_t *) reg_desc;
(gdb) bt
#0  core_set_initial_registers (thread=0xffef2018, thread_arg_voidp=<optimized out>) at linux-core-attach.c:299
#1  0xf79f43cc in dwfl_thread_getframes (thread=thread(a)entry=0xffef2018, callback=callback(a)entry=0x12520 <frame_callback>, arg=arg(a)entry=0xffef2088) at dwfl_frame.c:402
#2  0x00012ba8 in thread_callback (thread=0xffef2018, thread_arg=0xffef2088) at stack.c:458
#3  0xf79f41e0 in dwfl_getthreads (dwfl=0x28358, callback=callback(a)entry=0x12b80 <thread_callback>, arg=arg(a)entry=0xffef2088) at dwfl_frame.c:270
#4  0x0001150c in main (argc=8, argv=0xffef2354) at stack.c:731

Dropping the patches doesn't have any effect on the result.

Note that this is a 32 bit userland sparc, but the kernel is 64 bit.

I'm not sure what that code is doing there.  But it seems to be
looking at a 64 bit core file (x86_64, arm64, s390x) and then
create a 64 bit pointer is trying to dereference that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]