[lldb-dev] Linux/Posix spawning, signal masking

Todd Fiala tfiala at google.com
Wed Jan 22 10:00:14 PST 2014


Correct.


On Wed, Jan 22, 2014 at 9:55 AM, Greg Clayton <gclayton at apple.com> wrote:

> So the fix will 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
>
> Right?
>
>
> On Jan 22, 2014, at 9:54 AM, Todd Fiala <tfiala at google.com> wrote:
>
> > > It is indeed the right fix.
> >
> > Ok - I'll take care of that part.  Thanks!
> >
> >
> > On Wed, Jan 22, 2014 at 9:52 AM, Greg Clayton <gclayton at apple.com>
> wrote:
> > 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 <tfiala at google.com> 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
> > > lldb-dev at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
> >
> >
> >
> > --
> > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-943-3180
> >
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140122/b3d9ce67/attachment.html>


More information about the lldb-dev mailing list