From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101916 invoked by alias); 21 Jan 2020 05:41:49 -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 101907 invoked by uid 89); 21 Jan 2020 05:41:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=dialogue, disconnected, Sending X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2020 05:41:48 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3A9191E5F7; Tue, 21 Jan 2020 00:41:46 -0500 (EST) Subject: Re: [PATCH v2 2/4] Unregister the last inferior from the event loop To: "Maciej W. Rozycki" , Pedro Alves , gdb-patches@sourceware.org Cc: Jim Wilson References: From: Simon Marchi Message-ID: <2f8d9a63-db38-e5c0-d221-dd9b1e151e1b@simark.ca> Date: Tue, 21 Jan 2020 05:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00624.txt.bz2 On 2019-11-06 3:51 p.m., Maciej W. Rozycki wrote: > Fix an issue with GDB starting to effectively busy-loop (though still > accepting and interpreting commands) using the full processing power > available when a remote connection is forcibly terminated while the > target is running. > > This was observed with RISC-V/Linux `gdbserver' modified to hang after a > successful acceptance of a `vCont' packet, as follows: > > (gdb) set debug infrun 2 > (gdb) set debug remote 2 > (gdb) continue > Continuing. > infrun: clear_proceed_status_thread (Thread 22854.22854) > infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) > Sending packet: $Z0,10430,2#0c...Packet received: > Packet Z0 (software-breakpoint) is NOT supported > Sending packet: $m10430,2#c3...Packet received: 8147 > Sending packet: $X10430,0:#e6...Packet received: OK > binary downloading supported by target > Sending packet: $X10430,2:\002\220#7a...Packet received: OK > Sending packet: $m15555607b8,2#07...Packet received: 8280 > Sending packet: $X15555607b8,2:\002\220#be...Packet received: OK > infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 22854.22854] at 0x1555556ef0 > Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Packet received: OK > Sending packet: $vCont?#49...Packet received: vCont;c;C;t > Packet vCont (verbose-resume) is supported > Sending packet: $vCont;c:p5946.-1#b6...infrun: infrun_async(1) > infrun: prepare_to_wait > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [process -1], > infrun: status->kind = ignore > infrun: handle_inferior_event status->kind = ignore > infrun: prepare_to_wait > ^Cremote_pass_ctrlc called > remote_interrupt called > ^Cremote_pass_ctrlc called > infrun: infrun_async(0) > The target is not responding to interrupt requests. > Stop debugging it? (y or n) y > infrun: infrun_async(1) > Disconnected from target. > (gdb) infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [process -1], > infrun: status->kind = ignore > infrun: handle_inferior_event status->kind = ignore > infrun: prepare_to_wait > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [process -1], > infrun: status->kind = ignore > infrun: handle_inferior_event status->kind = ignore > infrun: prepare_to_wait > infrun: target_wait (-1.0.0, status) = > infrun: -1.0.0 [process -1], > infrun: status->kind = ignore > infrun: handle_inferior_event status->kind = ignore > infrun: prepare_to_wait > [...] > > 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. Simon