This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Don't kill inferior if there's a typo in the specified port.
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Doug Evans <dje at google dot com>
- Date: Sat, 11 Apr 2009 16:04:05 +0100
- Subject: Re: [RFA] Don't kill inferior if there's a typo in the specified port.
- References: <20090410231814.40469846AB@localhost>
On Saturday 11 April 2009 00:18:14, Doug Evans wrote:
> If there's a typo in the port gdbserver will kill the inferior.
To be clear to everyone else following this at home, this is for
"gdbserver --attach :badport PID", because the startup sequence is,
1) create or attach to inferior
2) open socket and wait for GDB connection
So, if #2 fails, we have to unwind 1. Previously, we simply
killed the inferior. That's bad when we have just attached to
to a running process, not so bad if we have created a new inferior.
> This fixes that by calling detach_or_kill_inferior_callback
> instead of kill_inferior_callback.
I think this makes sense. Even if we change the startup sequence
1) open and bind listen socket.
2) create/attach inferior
3) wait for GDB connection (`accept').
4) go debug
... which would also fix your problem, between #3 and #4, an error
can happen (although very rare), so we should detach from
any attachee from point #2.
The only thing that crosses my mind that could be strange, is
that if we detached from an inferior due to a gdbserver error/fatal
exit, while breakpoints are still installed, there's a risk that
the inferior will trip on them much later, causing inferior
SIGTRAP kamikaze. By killing the inferior immediately, the
cause/effect was very evident. :-) There's no best behavior
to chose, tough --- it's a compromise. I assume gdbserver will
be gaining Z0 (memory breakpoints) support in the near future,
which will make this point mostly moot. Plus, as you found
out yesterday, we're already broken, in the case of something failing
while debugging, and we error out while reopening the
connection --- meaning that this is all theory that won't
happen much in practice.
All this giberish to say I'm all for detaching instead
of killing. :-)
> It also moves the status message to the callback;
> it's only called when exiting gdb (and if that changes one can split
> the function into silent/verbose versions).
> An alternative is something like this:
> - fprintf (stderr, "Killing all inferiors\n");
> + fprintf (stderr, "Detaching or killing all inferiors\n");
> but will that be confusing?
"Detaching from inferiors we had attached to, and killing all others\n"
dunno, don't want to start a bikeshed-ish discussion on that.
> OTOH, if gdbserver ever gets used with 10's or 100's of processes,
> exiting with one line per process may be a bit much.
> OTOOH, the user might like to know what got detached and what got killed.
> I don't know, but I can change the patch to do whatever y'all prefer.
Yeah. If this is a real problem, then we could output something like,
Killing process(es) PID1, PID2, PID3, PID4, PIDnn.
Detaching process(es) PID1, PID2, PID3, PID4, PIDnn.
This should mitigate the problem, although if you're really attached to
100's of processes, it will still print a lot.
The other thing that crossed my mind was that if you had a bunch
of processes, the real error message that let to gdbserver bailing out
would be buried in the output many lines before all those
"Killing/detaching process X". The only version that doesn't
have this problem is the one that doesn't include any detail, like
the first option.
Anyway, I've no real inclination for any of these possible
> Ok to check in?
This is fine with me. Let's give it a few days in case Daniel or
others want to comment.
Thanks for documenting detach_or_kill_inferior_callback, btw ;-).