From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11946 invoked by alias); 23 Aug 2017 08:18:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 11583 invoked by uid 89); 23 Aug 2017 08:18:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:sk:static., opportunity X-HELO: mail-it0-f52.google.com Received: from mail-it0-f52.google.com (HELO mail-it0-f52.google.com) (209.85.214.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Aug 2017 08:18:28 +0000 Received: by mail-it0-f52.google.com with SMTP id 190so3528305itx.0 for ; Wed, 23 Aug 2017 01:18:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=wVmSFsH/y4S36uutplpM9M6VDdnKTP6f6o1Osysr+jw=; b=kUWLWPnUujWrXxq2NuF+iv6d2SHmjU4R31JnNrbkAuNgksLX7KgcFEsrQsku8Mble6 LvkuZBxIOtEtb3hWDABVjov10yb1eds0EVABKZj1b9XJPPg2pWBSykkEduBgnh1ikwQL IIipO1u1HAPKjGHgFuJOQcM6raP6eGlj9COp4d8ryPLETJ+9glowCAEZ1Ifqk6SrEBca t/pjqclIkcA0Ic12OV8uBKtLfW5rpm9skAm/KDrc4MLzx1jNoQPTNIu/yde3k5WdEuK3 a7ghfesrNLL3BpHpTjJ8Qqg8KdUvHk+dCrzYEkoh30sWsBOgKG6TqO7XtWUXFAIJaf1Y xpHw== X-Gm-Message-State: AHYfb5gvcIoVgx0sorEHSqFxwBxHbXzkdvlwMLkyp/1YBZ1nbRJ5Oks8 SnB2uCa+JCH7SA== X-Received: by 10.36.161.14 with SMTP id y14mr2876746ite.181.1503476306319; Wed, 23 Aug 2017 01:18:26 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id z12sm502963ioe.83.2017.08.23.01.18.24 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 23 Aug 2017 01:18:25 -0700 (PDT) From: Yao Qi To: Dmitry Antipov Cc: , Ryan Bissell , Mikhail Filimonov Subject: Re: Host GDB disconnect while waiting for tracee status change References: <5febbe3e-926f-78bb-db88-901b44e2e258@nvidia.com> Date: Wed, 23 Aug 2017 08:18:00 -0000 In-Reply-To: <5febbe3e-926f-78bb-db88-901b44e2e258@nvidia.com> (Dmitry Antipov's message of "Tue, 22 Aug 2017 16:23:03 +0300") Message-ID: <867exusnn8.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00060.txt.bz2 Dmitry Antipov writes: > Is there a feature/option/etc. to gracefully handle the situation when gd= bserver > sits waiting for tracee status change and the network connection is > getting lost? > I didn't try GDBserver under the case you described, but I find something related int GDB manual, https://sourceware.org/gdb/onlinedocs/gdb/Server.html "Therefore, when the connection drops unexpectedly, and GDB cannot ask gdbserver to kill its debugged processes, gdbserver stays running even in the target remote mode." GDBserver is able to handle this for tracepoint, which is called disconnected-tracing. https://sourceware.org/gdb/onlinedocs/gdb/Starting-and-Stopping-Trace-Exper= iments.html#disconnected-tracing With tracepoint, GDBserver knows what it should do when tracee status changed and don't have to communicate with GDB. > AFAICS in case of Linux, linux_wait_for_event_filtered() just enters > sigsuspend() > waiting for SIGCHLD and ignoring anything else, thus having no > opportunity to detect > any socket status changes even if the latter are signaled with SIGIOs req= uested > in enable_async_notification(). --=20 Yao (=E9=BD=90=E5=B0=A7)