Hi, > The frame above is always __default_sa_restorer() from /lib/libc.so.0. > At least that's what my backtrace outputs before it segfaults.
OK so either the unwind info for that frame is incorrect and sends libunwind into la-la-land, or whatever is above is not something libunwind understands. If libunwind gets sent to an invalid addresses, it's not always completely robust. Maybe the ARM bits fall-back handler require better protection to avoid stomping around in invalid address space regions? > For now I have backed out the experimental frame-chain unwinding for the > ARM platform. But I am willing to help you to debug this further. I know precious little about ARM specifically; maybe someone else on the list can help. I can try to help with the generic unwind issues. I'd try to figure out first if the failing address is valid. If not, figure out what's wrong in __default_sa_restorer() unwind info; if yes, understand why libunwind doesn't understand it - either why it doesn't find frame description for it, or what wrong assumptions the fallback handler makes. You can try reading "readelf -Wwf /lib/libc.so.0" output for the restorer and see if it matches the disassembly of the function. It's also useful to compare GDB's back traces with libunwind ones to see where things go wrong and why. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
