On 02/10/17 02:31 AM, John Knight wrote:
> A bit more input. I just added printfs to the console to determine where it 
> seg faults; I instrumented my function called log_stack_trace() which makes a 
> series of libunwind calls to do the backtrace. I see it calling 
> unw_getcontext(&uc), then unw_init_local((&cursor,&uc), and then it calls 
> unw_step(&cursor).  It does NOT return from unw_step(); Whatever is happening 
> in unw_step() is causing the signal_handler to kick in which reports signal 
> 11 (SEGV fault) received.  I guess next step is to instrument unw_step() to 
> see where it fails in its processing.  Unfortunately, I don’t know the 
> libunwind code at all… if anyone has some pointers on what to look for, I 
> would appreciate it.

As a guess, you could try instrumenting the
src/mips/Ginit.c:access_mem function.  On x86 & arm the memory is
validated before access using mincore or msync.  A couple printfs
before and after the memory access could verify.

Otherwise it's probably somewhere in the code that reads the eh_frame
or debug info code, which would be harder to debug.

_______________________________________________
Libunwind-devel mailing list
Libunwind-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to