From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18168 invoked by alias); 23 Jan 2020 01:12:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18160 invoked by uid 89); 23 Jan 2020 01:12:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: esa3.hgst.iphmx.com Received: from esa3.hgst.iphmx.com (HELO esa3.hgst.iphmx.com) (216.71.153.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Jan 2020 01:12:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1579741973; x=1611277973; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=62jsz6LUMZ+9Lz0Dxx9VGPTWiNdXrJUcpnlkF5aW3zE=; b=ewFkaWazKLijPLbAy6NCKah6Lye2P7Jnf5oLqCiIwY+uvw826m0X/69J J62PI62H2ols+hQPer4PamqBdq5zPrXzFsENiILWPJB6/SGNLFGRLsKCu exavK0NZJZprgQUmpT6I2MSqUpiyDJDRZJM/a3SwVLj9zcJHE7xxmpPB7 zGN2dPnQzbvwfSHDu/R4vO5oKG1CsGqjepimAG0h87gqmVXDrAHjmbR40 cFbiEX1SWBT2exl3pSf1SGoRcLGh0BGfAWc8dH3zf0XyOq3fxeZu/2F8H iETKiq5erpcEgdDgzLRBQjgNY/hdqSLIegnPoQ0XAHuPVjK/wr9xFyFZQ A==; IronPort-SDR: idxt4eYAMJxDnCGPSmilQqvR/jDaHaH/SjWBY/16H010eIDC32+Dc+jL94DKkM90dscieCKbB7 V4wuOlVv7HDQX919LxyEnTBXwdXx9sTLoxhF3fHWcOrYH3XVkoff6O8zg94z2vSl+74lIpcwBG 9sUuDG8edeNMtTHzi2Z2jv5ibEiGPQh+FWz9KfeI+LuJSHKU5lcQuKC3we2gWlcD8mx7RtreUL 8ue98hLh/HZWrel8+8oUs2piXb3+rmFjaX/KedXQXINFzqrW4bfwMC3kNVXV24WiQAL4vKMKqO dvQ= Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 23 Jan 2020 09:12:52 +0800 IronPort-SDR: PStvuueifmvMB5gguEkps3v6qtTtW62tCtqzdRBFqmtLc4lwVbBT2Y8ZtexJYSRFtSHcReadn6 mOMk8QJ9UuGD2gjMVRa/3/XcuVEStPueiovAyt/UCAVXLa2CorLE/Eg84aNpDBnX788tbiIgsk +hhVTM6t6p6hTFkWcbPwXOg/Civ0J/Bibdx894bGbqXGDN0NRxfqXh3l5/bBLAvm8SBoKQ8yvT wK02lM10lq95L+QNfWxRXbg9dJh88J+N8AzHQmsDcM80WLWHeIjlnGg4zskeY51LNhNvh42Acf 00mk4tAj4X+Y+O5XdZ2vmMgY Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2020 17:06:15 -0800 IronPort-SDR: HqmV9qXQJq9RQkezcJLYtV9TFm3fhHC8pdqzd817SD5rXrv/yaC/EJ+hw17GsNAkoJW33si+FC iltykdDR69f3dwtFtllHDoDhe5D2UKNRQ+BRO+tD+2lQG/RPSUUOzFo2QxyMe7Tdkdk6V8Of1F GeGAlDKcJZg6mNhuwS3B4aFoLdGbkVY9sgLW0AFOlkEeJjEhX3cSVR6+KFcQjytx/9/hv2SYeP ja747gpXoR/xfjgHmqnY9I6aU2dktqKwr7dJ16OxwzTIdVibnpLUHU1CGcUr5rplX+XANpS4+e l1M= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2020 17:12:50 -0800 Date: Thu, 23 Jan 2020 01:19:00 -0000 From: "Maciej W. Rozycki" To: Simon Marchi cc: Pedro Alves , gdb-patches@sourceware.org, Jim Wilson Subject: Re: [PATCH v2 2/4] Unregister the last inferior from the event loop In-Reply-To: Message-ID: References: <2f8d9a63-db38-e5c0-d221-dd9b1e151e1b@simark.ca> <323e416c-f0a9-ec14-c279-508c0245a479@simark.ca> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2020-01/txt/msg00726.txt.bz2 On Wed, 22 Jan 2020, Maciej W. Rozycki wrote: > > And because that returns TARGET_WAITKIND_IGNORE, which results in > > ecs->wait_some_more getting set by handle_inferior_event/prepare_to_wait, > > it results in the infinite loop in wait_for_inferior. > > Right. > > > Does that look accurate? > > Almost, except that code in question has since been heavily refactored > and the call to `target_wait' does not happen anymore. Now I need to > bisect the tree, find the offending commit and figure out whether it has > actually provided an alternative fix for the issue I have observed or just > papered it over by chance somehow. OK, I have tracked it down now. The semantics has changed with commit 5b6d1e4fa4fc ("Multi-target support"), and in particular this change: @@ -3719,17 +3910,28 @@ fetch_inferior_event (void *client_data) = make_scoped_restore (&execution_direction, target_execution_direction ()); - ecs->ptid = do_target_wait (waiton_ptid, &ecs->ws, - target_can_async_p () ? TARGET_WNOHANG : 0); + if (!do_target_wait (minus_one_ptid, ecs, TARGET_WNOHANG)) + return; + + gdb_assert (ecs->ws.kind != TARGET_WAITKIND_IGNORE); + [...] combined with the fact that the new `do_target_wait' wrapper (original `do_target_wait' has been renamed to `do_target_wait_1') retuns false if (ecs->ws.kind == TARGET_WAITKIND_IGNORE) means that the looping no longer happens and my problematic scenario has been deliberately taken care of, as a side effect if not as an intended one. This change (2/4) can therefore be dropped as no longer required. Again, thank you, Simon, for your assistance! Maciej