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
