Re: [RFA] Don't kill inferior if there's a typo in the specified port.

[Doug Evans <dje at google dot com>]

On Mon, Apr 13, 2009 at 11:49 AM, Doug Evans <dje@google.com> wrote:
> On Sat, Apr 11, 2009 at 8:04 AM, Pedro Alves <pedro@codesourcery.com> wrote:
>>> 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?
>>
>> Perhaps:
>>
>> ?"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.
>
> One reason why I like printing which processes were detached from and
> which were killed is: What happens if the process is gone shortly
> after gdbserver exits? ?Did gdbserver kill it, or did the detach screw
> up, or did the program crash on its own shortly after gdbserver
> detached? ?Tracking this down will be a pain without this info. ?One
> could add a verbose option to print such info I guess, but it might
> cut down on support costs if this info was always printed.
>
>>
>> Anyway, I've no real inclination for any of these possible
>> outputs.
>>
>>> 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 ;-).
>>
>> --
>> Pedro Alves
>>
>

Ok to check this in?
It does

Killing process(es) PID1, PID2, PID3, PID4, PIDnn.
Detaching process(es) PID1, PID2, PID3, PID4, PIDnn.

though I removed the commas for simplicity.
[I'm proactively avoiding some of the issues being raised. :-)]

Attachment: gdb-090430-gdbserver-attached-2.patch.txt
Description: Text document