labath wrote: > A reproducible way to trigger a crash is by doing a CTRL-C when the > DebugSymbols framework has forked to run dsymForUUID. The child process > inherits the handler and runs the signal handler against the parent process's > bogus SB state and crashes.
This may not be particularly relevant for the PR, but I find this an unlikely explanation. A child process (as in, the thing created by an `execve`, or `posix_spawn`) does not inherit parent's signal handlers. It just makes no sense as the child has a completely different address space from the parent. All signal handlers (except SIG_IGN) are reset to for the child process. It's true that the process created by `fork` inherits parent's signal handler, but I don't think that's what's you're referring to here. Forking in a multithreaded process is an extremely tricky business (the child has basically the same restrictions as a signal handler) and running any amount of non-trivial code there would break even without a `^C`. If I had to guess, I'd say it's getting killed by a plain SIGINT, because a ^C sends a SIGINT to the entire (foreground) process group. If that's the case, then nothing you do here will matter (though the patch may make sense nonetheless). The fix for that is to either launch it in a separate process group (eLaunchFlagLaunchInSeparateProcessGroup), or to block/ignore the signal in the child process (I don't think we have a mechanism for that, but it involves things like posix_spawnattr_setsigmask and posix_spawnattr_setsigdef. https://github.com/llvm/llvm-project/pull/195959 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
