This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Host GDB disconnect while waiting for tracee status change
- From: Pedro Alves <palves at redhat dot com>
- To: Dmitry Antipov <dantipov at nvidia dot com>, Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb at sourceware dot org, Ryan Bissell <rbissell at nvidia dot com>, Mikhail Filimonov <mfilimonov at nvidia dot com>
- Date: Wed, 23 Aug 2017 14:10:13 +0100
- Subject: Re: Host GDB disconnect while waiting for tracee status change
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3ACADC04D2F1
- References: <5febbe3e-926f-78bb-db88-901b44e2e258@nvidia.com> <867exusnn8.fsf@gmail.com> <98251d5d-646b-296c-acf6-43ec4accd4e0@nvidia.com>
On 08/23/2017 10:37 AM, Dmitry Antipov wrote:
> Immediately after killing gdb, gdbserver reports:
> ...
> client connection closed
> my_waitpid (-1, 0x40000001)
> my_waitpid (-1, 0x40000001): status(ffffffff), 0
> LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
> leader_pid=21352, leader_lp!=NULL=1, num_lwps=1, zombie=0
> sigsuspend'ing
> ...
>
> Next, a new instance of gdb is unable to reconnect:
...
> And it seems that there is no similar issue in a non-stop mode. For
> example:
...
> This way, a new instance of gdb can reconnect:
Right, because in non-stop mode, linux-low.c doesn't
usually block inside mywait....sigsuspend. See server.c:resume.
In non-stop mode, gdbserver waits for both socket events and
target events at the same time in the event loop. The
non-stop variant of the RSP is asynchronous.
Thanks,
Pedro Alves