[Bug gdb/17024] New: SIGSTOP handling is counterintuitive

["dje at google dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17024

            Bug ID: 17024
           Summary: SIGSTOP handling is counterintuitive
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

Run the attached program until it sends itself a SIGSTOP.
Then attach to it from gdb.

When I do "continue", gdb continually "resumes" the inferior by passing it
SIGSTOP, and thus "continue" becomes useless (set debug infrun 1 to see this).
I can resume the inferior with "signal 0", but I fear one thread may actually
be stopped on a signal I don't want it to ignore.
Plus I have to keep doing that until all threads are walked passed their
SIGSTOP.
It makes it hard to script gdb to "attach, thread apply all bt, continue &,
detach" (target-async of course).

I can also walk the threads passed their SIGSTOP by first "handle SIGSTOP
nopass".  I can also get the inferior going again with "shell kill -CONT <pid>"
(btw, gdb should have an easier way to write that).

I can imagine gdb is trying to do the right thing here.
If someone outside of gdb sends SIGSTOP then someone also needs to explicitly
send SIGCONT.  Plus if one wants to detach gdb leaving the inferior in the
state it was found, how does one do that? (if one does something different than
what gdb current does).  But the current behaviour isn't confusion-free.  We
need to add some clarity here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.