This is an archive of the discontinued LLVM Phabricator instance.

Change the default handling of SIGCONT to nostop/noprint
ClosedPublic

Authored by jingham on Oct 7 2020, 4:54 PM.

Details

Summary

The macOS LaunchServices agent sends a SIGCONT to the process it is managing in the process of starting up. This means processes that lldb attaches to when run by this agent stop somewhere in their startup with a SIGCONT. That's a bit annoying if you are trying to debug, and really annoying if you are running batch tests in the debugger, for instance.

That can be fixed by changing your "SIGCONT" handling, but when the issue came to my attention, it got me wondering whether stopping in the debugger for SIGCONT is really useful behavior? For the most part this means some job control operation was going on, but do you actually want to stop again after something, for instance, stopped & resumed your app? It seems to me unless you are explicitly debugging an interaction with this job control, stopping is just an annoyance.

So I'm proposing to change the default behavior to nonstop/noprint/pass from stop/print/pass.

I'm adding folks that are responsible for some of the other Unixen platforms as reviewers. If anybody has a good use case where this would be useful as a default, please speak up and I'll ditch this revision (and just get the clients that deal with LS to change the handling on their own.)

Diff Detail

Event Timeline

jingham created this revision.Oct 7 2020, 4:54 PM
jingham requested review of this revision.Oct 7 2020, 4:54 PM

As discussed offline I also think this makes sense.

labath added a comment.Oct 8 2020, 4:49 AM

I believe we should at least print/notify about the fact that the process has received a SIGCONT (like we do with SIGCHLD, which happens a lot more often). As for stopping, I don't really have a strong opinion.

One reason for keeping the existing behavior would be compatibility with gdb, but that's about all I can think of. The obvious use case for wanting to stop on SIGCONT is when you want to debug the job control behavior of some process -- e.g., vi (and even lldb) refreshes some state whenever it comes back from suspension. But this is not not something that comes up very often, I would expect.

Another possibility would be to try to detect these "useless" SIGCONTs and ignore them specifically (or just ignore SIGCONTs for the processes that are likely to receive them). I believe we had a patch for SIGSEGV and android like that at some point (i can't find a trace of it in the source, so I guess it did not land). OTOH, SIGSEGVs are not nearly as important as SIGCONT, so maybe a blanket ignore on the signal would be ok....

jingham updated this revision to Diff 297029.Oct 8 2020, 11:57 AM

Adopt Pavel's suggestion to do "nosuppress/nostop/notify" for SIGCONT instead of "nosuppress/nostop/nonotify".

This revision was not accepted when it landed; it landed in state Needs Review.Oct 8 2020, 3:24 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.