JDevlieghere wrote: > The SIGURG thing confused me a bit. The commit message makes it sound like > receiving a SIGINT does not interrupt a blocking syscall. This isn't true > because, while the signal _callback_ runs on a different thread, the signal > _handler_ (`static SignalHandler` in MainLoopPosix.cpp) runs on the thread > chosen by the kernel (same as before), and it is installed without > SA_RESTART, so it should interrupt syscalls. I think what's happening is (and > the code comments allude to that) is that the syscall gets interrupted, but > then the code checks some flags (which aren't set because we haven't called > `DispatchInputInterrupt` yet), and goes back to sleep. The subsequent SIGURG > yanks it out of that.
Yes, that's exactly right. The EINTR doesn't have an effect because Python's signal-check finds nothing pending yet. As you figured out, the SIGURG arrives later to give Python a second chance after the trip flag is set. > I'm wondering if we could avoid grabbing another signal for this (SIGURG > could in theory be used by some other part of the application). I think the > same effect could be achieved by sending another SIGINT to the main thread > (obviously, after we've restored the handler) -- and then setting a flag to > ignore the next callback invocation. WDYT? Wouldn't that be race-y with a real external SIGINT, which would look identical to the self-sent one? I guess we could check `siginfo_t.si_pid` in the MainLoop to ignore it if it's our own PID? Let me know if you prefer this over the `SIGURG` approach. My experience with a library installing signal handlers has been nothing but disastrous, so I'd be okay with preserving the current behavior and limitations to avoid that. --- The crash I'm looking at is a bit more involved than what I described in the PR description. I don't think what I'm seeing is the problem you're describing. This is what the crashlog looks like: ``` 0 lldb 0x00000001025160c4 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 lldb 0x0000000102514784 llvm::sys::RunSignalHandlers() + 112 2 lldb 0x00000001025169cc SignalHandler(int, __siginfo*, void*) + 300 3 libsystem_platform.dylib 0x0000000191c0e744 _sigtramp + 56 4 libsystem_pthread.dylib 0x0000000191c04888 pthread_kill + 296 5 libsystem_c.dylib 0x0000000191ad2d30 raise + 32 6 LLDB 0x000000011d17ba0c SignalHandler(int, __siginfo*, void*) + 324 7 libsystem_platform.dylib 0x0000000191c0e744 _sigtramp + 56 8 libsystem_trace.dylib 0x0000000191932618 _os_log_impl_flatten_and_send + 2544 9 libsystem_trace.dylib 0x0000000191947668 __os_signpost_emit_impl + 212 10 libsystem_trace.dylib 0x0000000191935188 _os_signpost_emit_with_name_impl + 40 11 LLDB 0x000000011d127e10 llvm::SignpostEmitter::startInterval(void const*, llvm::StringRef) + 160 12 LLDB 0x000000011cfd946c lldb_private::instrumentation::Instrumenter::Instrumenter(llvm::StringRef, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&&) + 136 13 LLDB 0x0000000117a321a0 lldb::SBDebugger::DispatchInputInterrupt() + 200 14 lldb 0x00000001024ffd90 sigint_handler(int) + 56 15 libsystem_platform.dylib 0x0000000191c0e744 _sigtramp + 56 16 libSystem.B.dylib 0x00000001a14ee5f4 libSystem_atfork_child + 56 17 libSystem.B.dylib 0x00000001a14ee5f4 libSystem_atfork_child + 56 18 libsystem_c.dylib 0x0000000191ab4d50 fork + 112 19 DebugSymbols 0x00000001abbc3bac CreateDSYMPathUsingShellCommand(__CFString const*, __CFString const*) + 164 20 DebugSymbols 0x00000001abbb902c CopyDSYMURLForUUIDWithOptions(__CFUUID const*, void const*, void const*, void const*, void const*) + 564 21 DebugSymbols 0x00000001abbb9114 DBGCopyFullDSYMURLForUUIDWithOptions + 48 22 LLDB 0x0000000117ccbb54 lldb_private::SymbolLocatorDebugSymbols::LocateExecutableObjectFile(lldb_private::ModuleSpec const&) + 568 ``` https://github.com/llvm/llvm-project/pull/195959 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
