This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Include putpkt in TRY_CATCH. PR gdb/51275
- From: Gareth McMullin <gareth at blacksphere dot co dot nz>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 21 Mar 2013 13:41:56 +1300
- Subject: Re: Include putpkt in TRY_CATCH. PR gdb/51275
- References: <CAL8qUbrD=fgMP7nE0O8tX=AXifUpQXas25o_4SfK4p79rfoUpw at mail dot gmail dot com> <CAL8qUbqjtBKJFJZ6dPS78Zh8Eb3b33U9JXTmn1pS3Le93xt7Rw at mail dot gmail dot com> <20130320170829 dot GA29887 at host2 dot jankratochvil dot net>
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