Florian Weimer <fweimer@xxxxxxxxxx> writes: > * 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. That's a good incentive to get managed runtimes to provide unwind information for JIT-compiled code. It can't be that hard: these same runtimes provide unwind information on Windows, where unwindability is mandatory. >> 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-/ SEH is good. So is vectored signal/exception support. >> 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, They don't have to be. I'd expect to be able to unwind a thread's stack while other threads are running. > and SIGPROF does not suspend the > entire process. Nor should it. > So I really don't think this can be made to work > reliably without kernel support. Sure it can. This scenario is one of many that would benefit from adding support to libc for multiple cooperating handlers for the same process. No kernel changes are required. Such a feature is feasible, useful, practical, and exists on other platforms. _______________________________________________ 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
