Re: Include putpkt in TRY_CATCH. PR gdb/51275

[Gareth McMullin <gareth@blacksphere.co.nz>]

On Thu, Mar 21, 2013 at 6:08 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Thu, 14 Mar 2013 03:02:29 +0100, Gareth McMullin wrote:
>> --- a/gdb/remote.c
>> +++ b/gdb/remote.c
>> @@ -10695,10 +10695,9 @@ remote_get_trace_status (struct trace_status *ts)
>>
>>    trace_regblock_size = get_remote_arch_state ()->sizeof_g_packet;
>>
>> -  putpkt ("qTStatus");
>> -
>>    TRY_CATCH (ex, RETURN_MASK_ERROR)
>>      {
>> +      putpkt ("qTStatus");
>>        p = remote_get_noisy_reply (&target_buf, &target_buf_size);
>>      }
>>    if (ex.reason < 0)
>
> Could you test this patch instead?
>         Fix 7.5 regression crashing GDB if gdbserver dies
>         http://sourceware.org/ml/gdb-patches/2013-03/msg00691.html

That patch doesn't solve the problem, as the exception is raised in putpkt when
the serial_write returns an error.  The problem is not an error reported by the
remote side, but an error reported by the host system because it is unable to
send.  Applying that patch and my patch together also does not solve
the problem,  as the exception raised is GENERAL_ERROR which is
pushed up by your patch.

> I guess it should also fix it but I probably cannot not replicate your serial
> stub conditions here.

I tried to reproduce with GDB server, because I expected similar behaviour on
a broken socket, but this actually works, on Linux, at least:

(gdb) tar ext localhost:2000
Remote debugging using localhost:2000
(gdb) set debug remote 1
... gdbserver killed from another terminal ...
(gdb) quit
Sending packet: $qTStatus#49...Remote connection closed
(gdb) quit

The send(2) ultimately called by putpkt actually succeeds on the broken socket,
while the write(2) used for Unix serial ports fails with EIO.  Changing
ser_unix_write_prim to fake success on EIO doesn't solve the problem as the
serial read doesn't distinguish between EOF and TIMEOUT.  I'll need to examine
ser-unix.c in more detail to see exactly what's going on there.

Is reworking ser-unix.c to behave more like ser-tcp.c a better fix than catching
the exception raised by putpkt?

Regards,
Gareth