This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: Process exit in multi-process, and gdb's selected thread.
- From: "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- To: "Pedro Alves" <pedro at codesourcery dot com>, <gdb-patches at sourceware dot org>
- Date: Tue, 17 Feb 2009 11:19:55 -0500
- Subject: RE: Process exit in multi-process, and gdb's selected thread.
- References: <200902170058.33653.pedro@codesourcery.com>
> -----Original Message-----
> From: gdb-patches-owner@sourceware.org
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Pedro Alves
> Sent: Monday, February 16, 2009 7:59 PM
> To: gdb-patches@sourceware.org
> Cc: Marc Khouzam
> Subject: Process exit in multi-process, and gdb's selected thread.
>
> Hi!
>
> I've been thinking about issues related to what to do with GDB's
> notion of selected thread, if we're debugging more than one process
> simultaneously, and the current processes exits.
>
> What would you think if GDB could get into this state,
> after a process exit? :
>
> (gdb) info threads
> 2 Thread 31176.31176 0x00007f0706154796 in ?? ()
>
> No selected thread. See `help thread'.
> (gdb) info inferiors
> 3 31176
> (gdb) c
> Continuing.
> Cannot execute this command without a live selected thread.
> (gdb) detach
> The program is not being run.
> (gdb) kill
> The program is not being run.
> (gdb)
>
> This would happen, e.g., if the current process (it was some other
> pid, not 31176) had exited or was detached from. Keep in mind that in
> non-stop mode, we prefer that GDB doesn't switch threads behind the
> user's back while he is typing some command. This way, when the
> current thread and inferior no longer exist, GDB switches to
> a state that
> should be safe, and the onus is on the frontend to switch to
> whatever thread it wants.
>
> In the past, I had solved this by spreading around some hacks
> that tried to detect the current inferior exiting, and switching
> to any other random live thread, but, that turned out to be: first,
> surprising in non-stop mode, in the case mentioned above; and
> second, surprisingly difficult to get right. I think this usually
> means that GDB shouldn't try to be smart (well, or I shouldn't).
>
> I've tried avoiding before getting to a state where GDB has
> no thread selected, when there are threads in the thread list. But,
> I don't think we'll be able to avoid it in the long run. E.g., when
> GDB gains ability to load more than on program (exec) at the
> same time,
> (say, "cat", and "grep"), even if "cat" is running already,
> it will fell
> natural to be able to select the "grep" executable as focus, thus,
> the selected thread in that case should be "null". (Also
> thinking about
> the possibility of GDB being able in the future to switch to some form
> of post-or-quasi-mortem debugging mode when a process exits,
> I'd want GDB
> to not switch threads to some other process on a process exit.)
>
> A bit related to this, is the hack we have currently that tags a
> few commands as being "safe to apply without a valid
> selected thread". This served its purpose when non-stop was first
> introduced, but, I think it's time we remove them, and start making
> the checks at a lower level. They are currently done at a too high
> level currently, which ends up getting in the way many times. We need
> more finer grained control over which operations can and can't be
> applied without a valid thread selected, so we need to push those
> checks down, more close to core code, or even to target code.
For what it's worth, I always thought it was risky to have such
a list of 'safe' commands. It just seemed to be asking for trouble.
> I'm thinking that we may need to extend the =thread-selected
> notification to tell the frontend that there's no thread selected,
> and perhaps the -thread-info,current-thread-id, output too.
Your patches does not do this yet, right?
> What do you think of all this, am I making sense? Or, does it
> sound like "let's hope he comes back to senses soon, for he's
> not making any"? :-)
>
> Here's my current patch that implements this, in case you
> have a stub around that implements multi-process (Hi Marc!).
I don't think you explicitely said it (or maybe I've read too
many emails today), but I believe you are suggesting that GDB
be allowed to be in a state where no thread is selected and
this state should be handled properly when receiving commands.
I didn't quite understand what responsibility falls on the
frontend with this suggestion.
I wanted to try to patch to see what you meant more clearly.
However, I think this patch applies to HEAD but HEAD does
not work with my stub yet (the -list-thread-groups --available
problem).
But I'm quite interested...
Marc