From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97895 invoked by alias); 21 Jan 2020 08:29:45 -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 97882 invoked by uid 89); 21 Jan 2020 08:29:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: esa6.hgst.iphmx.com Received: from esa6.hgst.iphmx.com (HELO esa6.hgst.iphmx.com) (216.71.154.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2020 08:29:34 +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=1579595375; x=1611131375; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=6bT7U/WCD3Q4cTY81m8aQIsf+pTzxsOx+JykZAsqwpA=; b=G5TmEkZxjvuLG1PB/NhCzPBbQQHXhhtK4ZP+X6mzyLUprXwmMhNQP/pO y5pVyPjkTE996+dw0Hiz1VTZ2mdeUgqhvDwrVZOOMxMVQRrIV3KAaeN8X ZGI6JLQ94y7a4fmHlKNg9wRzoz4DXjMVUor9JgyqT8gj2ny8Z0UX6z9PV hBguqWzekwzZFd7/hIAFo/WZ7jF3VjiMFVXXecRua5L221AOeT2Zu7krp Jhx7nA+PFsCLcBeDZvcj3xW9hMTqLB9CQI6xOHUL+NQLh8q9dDohQjH9L f5NHR5JfQxNk1CKNTJSKLnRvY3O3wODqyS1MYjd14DsB6jnwt6ybg6TK2 w==; IronPort-SDR: DkidvFE/QAn0aNrBD9cC1b+7eXf5EkQD7i5iymOmOKrQorMcn45YKmOs4xc6tMEcyRzvU8pmpS ViVj7Z+TGVVzT1hGsTH/0AfYymQKBH7/g6iY0cM5m00pOHzQKcD49YfhFWFKRkP/idymb5m4t+ yZMdnf5lXPE4MKteBFcH7ns/gbfvnjxphDpRVoaAXdrBAOK+VqxNTSGG6khZ15cKhpWq19yKhE +n39zReVBiDDOlhE1H+od7PJPzpeRaqLfMTg+qRzSxwAFVYf/g1m/GhD8LHx12bu8MFWrGcbdw EjU= Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 21 Jan 2020 16:29:34 +0800 IronPort-SDR: PIqK5QWL56VPdVn3KLUUlr8tcvCwCMUiZOsp7PqqBr1VAmTHNP4ypuFLIYOdV6iF0ac0zRrSmB O9qSVDrhphVLo/TQ4WcROeT/oOUN9ELikgGfXXgo9Mw0P1FqXXXVSA53i8kWEN0dT6yEk41FJ6 ejWvcc0fHW+5/e51GIrxydDPMmSRn/jRVxbwxNZtcOifT8s1bgzRgRDUU3lCSLGxMTK6TrgMCW mME+YfDJ9pledR48ojpXBX36AULfqSkP3fCy0rCTdBVLc4NypgVNBn15b+PzehjU/Q+F0bVOmn W0CON8BydVn6VrBXe7A8OB0z 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; 21 Jan 2020 00:23:00 -0800 IronPort-SDR: 7mrubZOkNSfn1TJ4xhEUR2TorKUp3a3zcsm4UVcMZUy7xwnvQ7HxJtU4FJj0fZ9Pto/bdrTjnL AbqD6Dr/ncfPB+BRhom+Y8P4h/HcLmScgacvZgxu3hvQc1tamhFCSOsem2Gp0kfMTb2te12umN 0cENCGH11kyyrZwtBFEgWa7e02iT2L5BOPiL7JALPcb0CD//THrp42QJY4srfo6A/OaZax9CfH 8mhHYUBmVwkc18Rot5xgbzzt+WJssRKNwTdlVrW6Up6hJHLAHWIMRntnDU6Mgkq+IxRDLXcAMy xgs= 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; 21 Jan 2020 00:29:32 -0800 Date: Tue, 21 Jan 2020 11:21: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: <2f8d9a63-db38-e5c0-d221-dd9b1e151e1b@simark.ca> Message-ID: References: <2f8d9a63-db38-e5c0-d221-dd9b1e151e1b@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/msg00626.txt.bz2 Hi Simon, > > This is because `remote_target::resume' enables the asynchronous event > > loop, as indicated by the first `infrun: infrun_async(1)' record above, > > and then the confirmation dialogue temporarily disables it and then > > reenables, as indicated by the second `infrun: infrun_async(1)' record > > above. The problem with that approach is that the reenabling also marks > > the handler for the `infrun_async_inferior_event_token' event ready, > > even though it was not before the temporary disabling, by calling > > `mark_async_event_handler' on it, and that triggers the infinite loop as > > there's no inferior anymore and consequently no event waiting that would > > stop it. > > I don't understand this description. Let's assume that the second call to > infrun_async indeed left infrun_async_inferior_event_token.ready to true. > Then I would expect the event loop to call it once, setting the ready flag > to false. After that, the ready being false, I don't see why the callback > of infrun_async_inferior_event_token would get called in a loop. Thanks for looking into it. It's been a while however, so my memory has become fuzzy on this. 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. 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? Maciej