From patchwork Wed Nov 6 20:51:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 35703 Received: (qmail 1171 invoked by alias); 6 Nov 2019 20:52:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 1162 invoked by uid 89); 6 Nov 2019 20:52:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=responding, acceptance, disconnected, 002 X-HELO: esa4.hgst.iphmx.com Received: from esa4.hgst.iphmx.com (HELO esa4.hgst.iphmx.com) (216.71.154.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Nov 2019 20:52:03 +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=1573073523; x=1604609523; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=sarHJEgN1l4KIlPQq/OH48s/kilv/CA9YaXwBIc0zsQ=; b=SS7Nn0eorLXxBjaqVvx4rVwX18mvap0QTVBuZfMNrYLT9avoYQznYmPo UMw48SGV5LqB0EdsWDsYNBIhgUJpuk7qlM+t/xm0yq2C93liqAIl/A57G 9wrFNb2C6nZYYvUbr26kP4FSX1ZymIbDCLpYcuO/2xEG0zSwZxrqdvbRP fWw1TYSVtOFOw5/Mz9xcKKoBs1OI+9S0ALRFRRAgnrwz/dbUwDppa6FZS 54jdtI+TOLtSJm7zyk2EJekrpfKpUaVPTNsQYSMJ1zGIdtekfjVT+1cvL RR3nLPc9ZHea5vey/MkVWndYJosHzv9mWwrM04wdaV5rD5jeQeMSAKlzq g==; IronPort-SDR: OAXO0zbsfd1QeuJq09F9VKKx7qQoW8ugDWEaQR6DE7BoxUyyVbMKAtTnuYVdGrkcVfw74rAfXR oMNSilhQnm3jEC1jBCACixrEhahi9Spo2WyXrdqOPF/0DJrCnS86K5v3Yy2FtIuCISSkccvW2p e6WckaKfb0Sdr1WH+lhDqbFDtQOq84hzm3Z65H3A1E7nUWsKRyuS9eeXx69rfirRCie7C1Fzzl 5lgdvHVlNgJQRPQWuobh2VV6/26gDHVotk5h+YA8Uye5OPPOuDQXg3MuEsx6sIQr7IYaWcBvlu 3R8= Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 07 Nov 2019 04:52:01 +0800 IronPort-SDR: npTv+cRn8AUMa78eHfl0XVaKkr5748AhrEOj9rPy24WoOqyobMUnUnLouKsPYcwBX5/BBtFdP9 w9S2OtFH7Jl6Ej0owXwOhlfHqIWndUzuyuP7oM/Qc2PlwXfTZohoWRY90kfEZSSxjlI3tM0hJH vaXBXOBoFapZzO+7VOge7DvUcP5f9r57HXPd4f3rq8cvy2G/93BkdZUtVjKDBhwpYZstDNsilV Mey68vkdaVQWF4j7HGrOHO0sbvg8giLUqVvGXnid5lKqbQG/b7HOdWMMZw4b02N6J2NOqsw4nP oD6mQLVibHqvHJ31aT5482bc Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 12:47:13 -0800 IronPort-SDR: MQq3HiUdHTgsQLdQ8tI5nzArIxkLOE/Aws9m+ZqkG3wIdPZqJ2IxhIK4UzBIXwokXhixmc9RS1 OPtFPXc78rWYYIaKKbTJg0jKubhLAzXcwP9CSWnW4lLGQiIX9ja122zv9JtNKTCJu1Roo6t2Ba cXBqfK28eAOJxZm6RftEqGzJJuUoj/hD0m8lcMt6SfrzGf/F/opIrWgwmloDXZxlcaXeYSCsfV Dmf3vxPdrTGmHgtfbBQ88iHsfjSGdEYFqmt4Lv27cA4DV5a3o4GUue8FU17/DP7wT+ibTalwF8 X4c= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 12:52:01 -0800 Date: Wed, 6 Nov 2019 20:51:59 +0000 (GMT) From: "Maciej W. Rozycki" To: Pedro Alves , gdb-patches@sourceware.org cc: Jim Wilson Subject: [PATCH v2 2/4] Unregister the last inferior from the event loop In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 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. Unregister the `infrun_async_inferior_event_token' event from the loop then when the last inferior has gone. The final part of the session now looks like: ^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) infrun: infrun_async(0) Disconnected from target. (gdb) and the looping does not happen anymore. gdb/ * target.c (target_stack::unpush): Unregister the last inferior from the event loop. --- New change in v2. --- gdb/target.c | 6 ++++++ 1 file changed, 6 insertions(+) gdb-unpush-target-async.diff Index: binutils-gdb/gdb/target.c =================================================================== --- binutils-gdb.orig/gdb/target.c +++ binutils-gdb/gdb/target.c @@ -634,6 +634,12 @@ target_stack::unpush (target_ops *t) implementation don't end up in T anymore. */ target_close (t); + /* If this was the last inferior, then make sure it's been unregistered + from the event loop so that we don't get distracted by spurious + inferior output. */ + if (!have_live_inferiors ()) + infrun_async (0); + return true; }