From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vbNoOaJj92NOnjsAWB0awg (envelope-from ) for ; Thu, 23 Feb 2023 08:01:22 -0500 Received: by simark.ca (Postfix, from userid 112) id DF0E91E222; Thu, 23 Feb 2023 08:01:22 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6186D1E128 for ; Thu, 23 Feb 2023 08:01:22 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F06953858288 for ; Thu, 23 Feb 2023 13:01:21 +0000 (GMT) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by sourceware.org (Postfix) with ESMTPS id 5F9E63858C5E for ; Thu, 23 Feb 2023 13:01:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F9E63858C5E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f49.google.com with SMTP id t13so10547376wrv.13 for ; Thu, 23 Feb 2023 05:01:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tVIkYQO4Whul4uqBf1wIw2fuLFUn+La9Hr85H8EUTiA=; b=I0OOsGrxrVxf0sQ5dU8lgsIVKJMP2vlZE283URWM0dBgm2SZOfg2x8qgnSR0BiGdxJ B2ucpeZH5Ax5/GUDrZxEBGtgcObj4w5OCfA+vhLMd0aVGFVO5PAp+ElBQ9owZbeT784p G6COnAad4bClpTo7g2Zm98hH52EYPMhklIaao8E1zeidQPgDOndERJF4td95u1Rt7PhN yFuE/9vZgu8KGv49HOjJBA1J50/jg0JCqgx4XTJimTwYxD8J1sc6XuTGW63raFosiqAt uA0Bb8/G64jtm066iXK8YIg7zObmBxlyDMSlptZjHFtBRomLqRZtMMjHv17DemkhVpt6 vrxQ== X-Gm-Message-State: AO0yUKXcGDMdLUA097PigdK9B6YrqQfG/pGfEGKACeVsyz+1HJUcfNIn 1xXJyem7rckb2FNmA7jr9XFexJjHHmm9ww== X-Google-Smtp-Source: AK7set9Cwqasx8slpxWyoSX9RVSWcc6ROga2KGBBWveTIzMmCZumHGyDBfrZfEh05fHXcrHe2rkLvw== X-Received: by 2002:a05:6000:1146:b0:2c5:8c04:efbf with SMTP id d6-20020a056000114600b002c58c04efbfmr8674857wrx.13.1677157268939; Thu, 23 Feb 2023 05:01:08 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id z20-20020a7bc7d4000000b003e6efc0f91csm9617347wmk.42.2023.02.23.05.01.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Feb 2023 05:01:08 -0800 (PST) Subject: Re: [PATCH v5 0/8] Fix gdb.base/gdb-sigterm.exp failure/error To: Kevin Buettner , gdb-patches@sourceware.org References: <20230222234613.29662-1-kevinb@redhat.com> From: Pedro Alves Message-ID: <44a9cd21-b40e-30d8-b9b2-4502e1905526@palves.net> Date: Thu, 23 Feb 2023 13:01:07 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <20230222234613.29662-1-kevinb@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi! On 2023-02-22 11:46 p.m., Kevin Buettner wrote: > This series fixes the failure in gdb.base/gdb-sigterm.exp when > running in environments with glibc-2.34 or later. > > It contains only a few changes from the v4 series posted in > January: > > https://sourceware.org/pipermail/gdb-patches/2023-January/195579.html > > This series drops part 6 from v4, "Call quit_force for > gdb_exception_forced_quit in safe_execute_command", in favor of > Pedros's already committed/pushed "Simplify interp::exec / interp_exec > - let exceptions propagate". > > In his review of the v4 series, Pedro asked for a new function, > set_force_quit_flag() which sets sync_quit_force_run and also calls > set_quit_flag(). This is done in v5's part 7, "Introduce > set_force_quit_flag and change type of sync_quit_force_run". > > This series also makes several other minor changes that Pedro had > asked for. > > I've added Tested-by tags for Tom de Vries for all parts except > for the new part 7 mentioned above. > > Pedro has approved parts 1, 2, and 3; I added Approved-by lines > referencing Pedro to those parts. > Thank you! > Pedro gave a sort of half-hearted approval for part 4, "Python QUIT > processing updates". I haven't marked this commit with an Approved-by > line yet. I would, however, like to commit this one as is. I think > that implementing Pedro's suggestion of throwing a Python exception > corresponding to the forced-quit and then calling set_force_quit_flag() > when returning out of the Python interpreter is doable, but probably > also somewhat tricky/involved. Rather than going a few more rounds on > this series in an attempt to get those details correct, I'd prefer to > push the Python and Guile portions of the current series and then > work on a separate series implementing Pedro's suggestion. The Python > and Guile portions of this series will cause GDB to exit on receipt of > a SIGTERM, but might not be safe for future GDB in which Python (or > Guile) might be called from GDB from very low level code in which > certain data structures are not in sync. If this should happen, we > might run into other problems anyway if those low-level invocations of > Python from GDB want be able to call arbitrary methods in GDB's Python > API. (We would need to make sure that all of GDB's Python API is safe > to use with out-of-sync data structures. I think it's possible that > some case might trigger the same assert which prompted this series.) Agreed. > > Kevin Buettner (8): > Introduce gdb_exception_forced_quit > Handle gdb SIGTERM by throwing / catching gdb_exception_force_quit > Catch gdb_exception_error instead of gdb_exception (in many places) > Python QUIT processing updates > Guile QUIT processing updates > QUIT processing w/ explicit throw for gdb_exception_forced_quit > Introduce set_force_quit_flag and change type of sync_quit_force_run > Forced quit cases handled by resetting sync_quit_force_run For the whole series: Approved-By: Pedro Alves Pedro Alves