* Mark Wielaard: > On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote: >> If the unwind information is incomplete, this … >> >> > 7) signal handler unwinds the calling thread however it wants (and can >> > sleep and take page faults if needed) >> >> … might encounter segmentation faults and terminate the process. So >> far, incorrect unwind information (whether it's a clobbered frame >> pointer, or missing DWARF information about clobbered registers) is not >> a problem, but it's kind of hard to validate this information from >> within the process itself. Maybe we'd have to add a magic memcpy first >> to the vDSO, which the kernel recognizes based on the code addresses, >> and suppresses sending the signal for it. > > Yeah, I am not too afraid of that happening with an .eh_frame based > unwinder unless someone deliberately produced a bad table (or dlcloses > a library which still has code on the call stack). You still have to be > careful about the stack bounds of course. We won't have unwind data for JIT-compiled code, including libffi trampolines. We could stop backtracing there (what does the ABI say about frames without unwinding information?), but I'm not sure if that's going to be useful for the desktop. > But it is something to keep in mind, accidents happen. I assume that > any (seg) fault caused by the unwind signal thread will simply end that > contribution of user space to the backtrace (instead of really > generating a SEGV) That smells like SEH. 8-/ > But it is tricky to handle that without kernel support. As a fallback > you could install a SIGSEGV handler that handles the fault and somehow > makes the original SIGPROF based handler (if you use that) sigreturn. Signal handlers are process-wide, and SIGPROF does not suspend the entire process. So I really don't think this can be made to work reliably without kernel support. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
