From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outbound-ss-820.bluehost.com (outbound-ss-820.bluehost.com [69.89.24.241]) by sourceware.org (Postfix) with ESMTPS id 4234B3858CDA for ; Fri, 28 Jul 2023 20:50:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4234B3858CDA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw11.mail.unifiedlayer.com (unknown [10.0.90.126]) by progateway2.mail.pro1.eigbox.com (Postfix) with ESMTP id 26A1C10047FA9 for ; Fri, 28 Jul 2023 20:50:32 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id PUPwqOBfry6mjPUPwqXT6F; Fri, 28 Jul 2023 20:50:32 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=PJTKRdmC c=1 sm=1 tr=0 ts=64c42a18 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=OWjo9vPv0XrRhIrVQ50Ab3nP57M=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=ws7JD89P4LkA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=SCmuGnsmItwBYaqc8i0A:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XI6+4UGgF625wVdvkzJrZ8n8M0xohAJoldOeaoLGlWw=; b=NOrYsaBYycpeB6sL5GiNOxx5MH /bnyb4sA45hdoGCCs2eBTJ5UkD7ubGDdvUTZ3ITVoUr7d6ByoPphwFq/6Op+KmicUhTV1sJvkk2ly QfYPZ1008KiujNAhfQ4qZ5ciG; Received: from 75-166-135-140.hlrn.qwest.net ([75.166.135.140]:57188 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qPUPv-002Ufn-2r; Fri, 28 Jul 2023 14:50:31 -0600 From: Tom Tromey To: Dmitry Neverov Cc: Tom Tromey , Dmitry Neverov via Gdb Subject: Re: Canceling a long running gdb/mi command References: <877cqmk60b.fsf@tromey.com> X-Attribution: Tom Date: Fri, 28 Jul 2023 14:50:30 -0600 In-Reply-To: (Dmitry Neverov's message of "Fri, 28 Jul 2023 12:02:30 +0200") Message-ID: <87y1iz92w9.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.135.140 X-Source-L: No X-Exim-ID: 1qPUPv-002Ufn-2r X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-135-140.hlrn.qwest.net (prentzel) [75.166.135.140]:57188 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3019.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Dmitry> I was wrong, it works, but one might need to send several Dmitry> SIGINTs. In my case, the first exception thrown by quit() was Dmitry> caught and ignored in cp-support.c replace_typedefs(), and the Dmitry> gdb/mi command continued running. The second one was caught Dmitry> and handled in cp-support.c inspect_type() which made a slow Dmitry> -var_list_children command to complete. Catching and ignoring like that seems bad. IMO only non-QUIT exceptions should be caught in this way, at least in most places. I see a lot of violations of this idea though -- grep says 282. So that is not good. Though on reflection, not all of these are really incorrect, because the 'try' block may not end up calling QUIT. Fixing this seems like a bit of a pain. Probably some of those catches really should handle QUIT as well. Also it seems like some kind of region-based QUIT suppression has to be done, because there are parts of gdb that can't really be QUIT from (e.g., the DWARF reader is basically unprepared for this). I wonder whether varobj can really handle interruption. That code is pretty hard to work on... anyway it would be interesting to see a stack trace from your scenario. Dmitry> Is it by design and clients should send SIGINTs repeatedly? No. Dmitry> Do I understand correctly, that it is safe to send a SIGINT when Dmitry> no gdb/mi command is running? Meaning it won't terminate Dmitry> gdb. I've tried and it works, but maybe I was lucky. Yes, I think this should be fine. However, if the inferior is running, I think it may cause an inferior stop. Tom