From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by sourceware.org (Postfix) with ESMTPS id 6D224385840F for ; Mon, 27 Sep 2021 18:24:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D224385840F 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-f47.google.com with SMTP id x20so8848572wrg.10 for ; Mon, 27 Sep 2021 11:24:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Awn6SbqYzQcVFqCI2V+KK/2L1Pe94BuPrMit5q9eEfQ=; b=yXIslWfBkp6fQkzJ0wjK2AhOdAeCEdpBQzo5FQKjOtg4VMw8pMjl2Ubg4cNx00/lRT MxsJh+cVaBLPYxF8z7RWXrcDMsletHKDiDr8m1Trkig6zjqqTmu5Gq0XuYI6wuDPlDV2 FhJOPx8A1cpu6/m12IaIoMC8J/doBXR0nAEMrqrbgv4Ws3ZnGaawWAXHzAyoKiR3e6pM 5o2Bu6jUCafO0+g9GhRGQXffBkGiarJINqexT+6zbAtW9L/Qb/OfHylhFIMBD8XOHZjk sFvz9dmSPlu801PHXQxOV8bE1frkoh3kg4e1ftI6N/eOHzEEn643W40xowzlSmz4MBAv lcZQ== X-Gm-Message-State: AOAM531aRzvzlAZU4xOR7DLUVoAjZWBt0HZl852cUQuHnQnytqr8bvVh +uobWHU4ZhgDFpg87pOVmPvg8QmA9aY= X-Google-Smtp-Source: ABdhPJxocx2cpfd9qNOBLGvw/2Sr7q3v4Eftr5+9CTxvl59wnv8axOyAjq3Fz76W+eBflC8GPn4WVg== X-Received: by 2002:adf:f0c7:: with SMTP id x7mr1530564wro.432.1632767094009; Mon, 27 Sep 2021 11:24:54 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:46bc:d03b:7b3a:2227? ([2001:8a0:f932:6a00:46bc:d03b:7b3a:2227]) by smtp.gmail.com with ESMTPSA id q7sm18459403wrc.55.2021.09.27.11.24.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Sep 2021 11:24:53 -0700 (PDT) Subject: Re: [PATCH v2 4/6] Python QUIT processing updates From: Pedro Alves To: Kevin Buettner , gdb-patches@sourceware.org References: <20210822231959.184061-1-kevinb@redhat.com> <20210822231959.184061-5-kevinb@redhat.com> Message-ID: <764a5dcc-4391-ead3-61c1-82359ff80bf7@palves.net> Date: Mon, 27 Sep 2021 19:24:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210822231959.184061-5-kevinb@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 27 Sep 2021 18:24:56 -0000 On 2021-08-23 12:20 a.m., Kevin Buettner via Gdb-patches wrote: > See the previous patch in this series for the motivation behind these > updates. > > This commit contains updates to Python's QUIT handling. Specifically, > it makes sure that a SIGTERM sent to GDB will be propagated to the top > level. While there are instances where we want to allow python code > to catch Ctrl-C / SIGINT (and possibly) swallow it, I don't think we > want that behavior for SIGTERM. Therefore, there are cases where > sync_quit_force_run is checked explicitly. In other cases, I > was able to defer the decision to GDB_PY_HANDLE_EXCEPTION. (My goal > was to minimize explicit references to sync_quit_force_run.) Something to ponder about is whether having a distinct gdb_exception_sigterm would be cleaner. > --- > gdb/python/py-finishbreakpoint.c | 6 ++++-- > gdb/python/py-gdb-readline.c | 12 ++++++++---- > gdb/python/py-symbol.c | 4 ++++ > gdb/python/py-utils.c | 4 +++- > gdb/python/py-value.c | 4 ++++ > 5 files changed, 23 insertions(+), 7 deletions(-) > > diff --git a/gdb/python/py-finishbreakpoint.c b/gdb/python/py-finishbreakpoint.c > index 1d8373d807e..120e40db6eb 100644 > --- a/gdb/python/py-finishbreakpoint.c > +++ b/gdb/python/py-finishbreakpoint.c > @@ -270,8 +270,10 @@ bpfinishpy_init (PyObject *self, PyObject *args, PyObject *kwargs) > } > catch (const gdb_exception &except) > { > - /* Just swallow. Either the return type or the function value > - remain NULL. */ > + /* Swallow everything except for a SIGTERM sent to GDB. Either the > + return type or the function value remain NULL. */ > + if (sync_quit_force_run) > + throw; AFAIK, it is not safe to let C++ exceptions cross the Python runtime, as Python is written in C. The issue may be papered over on x86-64 Linux and there everything is built with -fasynchronous-unwind-tables. Even if it looks like it works, Python doesn't see the exception at all so isn't given a chance to properly cleanup as the exception unwinds the stack. The same concern applies to the rest of the patch.