From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44382 invoked by alias); 22 Jan 2020 17:06:52 -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 44373 invoked by uid 89); 22 Jan 2020 17:06:51 -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=Almost, H*MI:sk:2f8d9a6, wish X-HELO: esa1.hgst.iphmx.com Received: from esa1.hgst.iphmx.com (HELO esa1.hgst.iphmx.com) (68.232.141.245) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Jan 2020 17:06:49 +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=1579712809; x=1611248809; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=LYmA8gfhBEhrh6YleZ7knyLguwCePwDb2HvWCFRvapk=; b=SC90eHkryF0+chSjFxqTJxVT8+8Hcb/AxgANPs91VoHb8K7M5NnBcFQi KyKY/Dp3ebyOjBTfnkr5VQogBFLpnOG6GPhvy7qCe0XWqNTQKnngDlM4N udk5sXK3jIGvklkLiFhryXRY55eKUZTyQBO7OmS096TrMyYfYwJ8OxjRK xPI5Yxa+1O7i+6chyHXElhH4KJ1CeE6UpW+4K5UJB0UJmAwAdmG8p2tz+ lvIFMni3hBKDbHBLgp4YRokQKNY4DvHcGvLkewfGPnBJL/Yviu9Ctq9pO cgKbuKRkNS31dTk6UIZhD5/d5OZc89rD4Nly6FWjjRTsHnQ+vfseIk6wP g==; IronPort-SDR: jDTwQG4feJoqiYKh5PkTb6fagIaWOzwlwOxH7EOhgWf9TBxKaNSUuy71hZ7UDoMf/xWJZ06pih 0xSK9vdmljjxkq2p6gD+Oh5SvcGjgfbE//87KUWTnjHl2nq4gbKwII+K0VRIIiYGbEbKETtS6J AoOmOkqmqEVgyLim1n83FLThNs+mGHuQg31x1T2DSYALFDeVMPzas6NxkoHdGbOa+cQOSFoEIM GAHmAUstI5gDLdMIClTV9DuXjAjIHJGh29iZinupi5kJUG076dqv+ZAYbZUnFihChd5bUAdEMS xrk= 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 01:06:48 +0800 IronPort-SDR: JL1IocRnGxoIAFmedNEcdDaN+n5EVbADtr2hmwjaXGX+qfGSpwbbjpnevvOh5aosiAxCv3L8ic +62xu2oOrYp9Uo5iFQCY5kxYeCWzGTBuj8vISv5A1ecCrR4H6aihu/aAbn8/Ep4EPky6slT5ta Npzl72fHvH6+9MQFMJWowUyxSOmDaR1TbMhsVRYuF/4U24g9yy1OMTMAfLhONY3wXz+/cEls7s rRfYKPUryR7Mmkkfu0UWI/72q34Eg3NFV2YVQpn8Qrq4oDZWn4BIrCBwzaxyJ2Q+KIvRwe1TYJ hWID57Fh+70icnw7xE6i2/HK 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 09:00:12 -0800 IronPort-SDR: 2PiheO/lA6kipql4A8ZzkHeFi4DId5D5ZbEnOjlEzPnPjfn6mOH5/XkMJCCL3cPpWGWd0sR/TN lFisdTLwBTu1i7elPbPGE74zFbesdLGg+zq9hmNuMWR/a7ZSte0+lKi74YMkW20mUQGQlQIhGt +JANsuUgUIrFBTTUmal7xrVG6DWgmjL9jMyGRMQ3NYh0ycPMgsrqtBljzKXDaMJw1/rOMHgFDY g7bH1VzThtf5JyydfFQE9QvTxVsRhTnpoVeOcQLF2qJRxO4ZIWCWtRT6WQjbQTS/DcDo9Sa/M6 D1I= 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 09:06:47 -0800 Date: Wed, 22 Jan 2020 17:35: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: <323e416c-f0a9-ec14-c279-508c0245a479@simark.ca> 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/msg00683.txt.bz2 On Tue, 21 Jan 2020, Simon Marchi wrote: > > I have therefore gone reading through the code again and what I can see > > is that in the async mode the `ready' (readiness) flag is never cleared: > > see `infrun_async' and `remote_target::async', which are the only places > > to call `clear_async_event_handler' and then only when the async mode is > > being disabled. > > The ready flag is also cleared in `check_async_event_handlers`, just before > invoking the callback. So I was thinking, why would the callback get called > repeatedly if the ready flag is cleared just before it gets called, and > there's nothing setting it back to true. The answer is probably that the > busy loop is within that callback, as seen below? Indeed it was cleared in `check_async_event_handlers' and then set again via `mark_infrun_async_event_handler' in `prepare_to_wait' called from `handle_inferior_event'. > > On the other hand waiting for an inferior event does get disabled in > > `handle_inferior_event' regardless of the readiness flag, by calling > > `stop_waiting', for certain events, but not for TARGET_WAITKIND_IGNORE. > > Instead for that event `prepare_to_wait' is called, which makes sense to > > me because such an event does not indicate whether waiting should or > > should not be disabled, and with an asynchronous target you can normally > > (i.e. if not indicated by a specific event received otherwise, e.g. > > TARGET_WAITKIND_EXITED) expect a further event to be received anytime. > > > > Does this clarify the problematic scenario to you? > > Ok, so if I understand, the infinite loop is this one, inside > wait_for_inferior? > > while (1) > { > ... > > /* Now figure out what to do with the result of the result. */ > handle_inferior_event (ecs); > > if (!ecs->wait_some_more) > break; > } Nope, it was in `start_event_loop': while (1) { ... result = gdb_do_one_event (); ... if (result < 0) break; } calling `check_async_event_handlers', `infrun_async_inferior_event_handler', `inferior_event_handler' and ultimately `fetch_inferior_event': /* Now figure out what to do with the result of the result. */ handle_inferior_event (ecs); if (!ecs->wait_some_more) ... > After the remote target has been unpushed, the remaining target is probably > just the "exec file" target, which does not provide a ::wait implementation, > and therefore inherits default_target_wait: > > ptid_t > default_target_wait (struct target_ops *ops, > ptid_t ptid, struct target_waitstatus *status, > int options) > { > status->kind = TARGET_WAITKIND_IGNORE; > return minus_one_ptid; > } And it was `dummy_target::wait' indeed invoking `default_target_wait'. > 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. Thanks for your input, I wish it happened earlier, before the code has been rearranged, sigh... Maciej