It is indeed the right fix. Host.mm has a mac specific version which does this:
sigset_t no_signals;
sigset_t all_signals;
sigemptyset (&no_signals);
sigfillset (&all_signals);
::posix_spawnattr_setsigmask(&attr, &no_signals);
::posix_spawnattr_setsigdefault(&attr, &all_signals);
Compared to the incorrect version you noticed in Host.cpp:
sigset_t no_signals;
sigset_t all_signals;
sigemptyset (&no_signals);
sigfillset (&all_signals);
::posix_spawnattr_setsigmask(&attr, &all_signals);
::posix_spawnattr_setsigdefault(&attr, &no_signals);
(notice all_signals and no_signals are reversed in the last two function calls
in Host.cpp.
You might compare the "LaunchProcessPosixSpawn" in Host.mm and try and just
copy it to Host.cpp and see if it works. I can't find anything darwin specific
in the code after a quick glance and we have used the Host.mm
LaunchProcessPosixSpawn() for a few years now, so it is definitely tested...
So the fix would seem to be:
1 - Remove LaunchProcessPosixSpawn() from Host.mm
2 - Copy it over into Host.cpp
3 - Make sure LaunchProcessPosixSpawn is compiled for Apple builds as well in
Host.cpp
On Jan 21, 2014, at 10:49 PM, Todd Fiala <[email protected]> wrote:
> Hi all,
>
> In source/Host/common/Host.cpp, there is a posix process spawning method
> called LaunchProcessPosixSpawn. On my Linux system, it is used to start the
> target process in lldb-gdbserver. It looks like FreeBSD uses it as well.
> Most of the Platform launchers appear to funnel to it as well (via
> Host::LaunchProcess ()).
>
> There is a section of code in LaunchProcessPosixSpawn that masks all signals
> for the child process that is started up:
>
> ::posix_spawnattr_setsigmask(&attr, &all_signals)
>
> When that is set, it seems to be preventing the child from receiving
> everything except the non-blockable signals. This has the effect of (at the
> very least) blocking SIGINT (i.e. ^C from the keyboard) and SIGTERM (standard
> unadorned "kill pid"). This appears to be the cause of a few bugs as I try
> to get lldb-gdbserver working on Linux. For example:
>
> 1. hitting ^C on an lldb-gdbserver that spawned a debuggee target process
> would kill the lldb-gdbserver, but not the debuggee target, which continues
> to run.
>
> 2. sending a SIGTERM (kill {debuggee pid}) while it is getting debugged and
> running is ignored.
>
> 3. sending a SIGTERM to the debuggee after issue #1 (where lldb-gdbserver is
> no longer running) is ignored.
>
> 4. killing lldb-gdbserver from an attached lldb that shuts down and kills the
> remote does indeed kill lldb-gebserver, but does not kill the target process.
>
> (Of course sending a 'kill -9 {debuggee pid}' works fine to kill the target
> process).
>
>
> I've modified this method locally to not mask any signals:
>
> ::posix_spawnattr_setsigmask (&attr, &no_signals)
>
> This seems to address all the problems I had above for lldb-gdbserver as
> signals propagate properly, and the target responds correctly to signals sent
> when the parent dies, etc.
>
> I've also run all the existing tests (on my system, that amounts to 275 tests
> that really run), and those are all passing.
>
> However, given that so much code flows through here (or at least appears to)
> that is not directly related to the lldb-gdbserver --- i.e. local
> linux/FreeBSD debugging --- I'm highly skeptical that this is the right fix.
> I did try using local debugging with lldb with my change in place, and that
> seemed to work fine. But I'm thinking that perhaps the signal blocking was
> intended and that behavior is needed in some cases that (perhaps) are not
> covered by tests that run on Linux.
>
> Any thoughts on why all the signals were getting masked on process spawning?
> Does that change look okay as is?
>
> Thanks!
>
> Sincerely,
> Todd Fiala
> _______________________________________________
> lldb-dev mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
