From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126390 invoked by alias); 22 Aug 2017 13:23:58 -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 126357 invoked by uid 89); 22 Aug 2017 13:23:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:538, opportunity X-HELO: hqemgate15.nvidia.com Received: from hqemgate15.nvidia.com (HELO hqemgate15.nvidia.com) (216.228.121.64) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Aug 2017 13:23:56 +0000 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com id ; Tue, 22 Aug 2017 06:23:27 -0700 Received: from HQMAIL101.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Tue, 22 Aug 2017 06:23:27 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 22 Aug 2017 06:23:27 -0700 Received: from UKMAIL102.nvidia.com (10.26.138.15) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 22 Aug 2017 13:23:08 +0000 Received: from localhost.localdomain (10.21.45.12) by UKMAIL102.nvidia.com (10.26.138.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 22 Aug 2017 13:23:04 +0000 To: From: Dmitry Antipov Subject: Host GDB disconnect while waiting for tracee status change CC: Ryan Bissell , Mikhail Filimonov Message-ID: <5febbe3e-926f-78bb-db88-901b44e2e258@nvidia.com> Date: Tue, 22 Aug 2017 13:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL102.nvidia.com (10.26.138.15) X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00043.txt.bz2 Hello, Is there a feature/option/etc. to gracefully handle the situation when gdbserver sits waiting for tracee status change and the network connection is getting lost? 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 requested in enable_async_notification(). Thanks in advance, Dmitry