From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id B89113858C5E for ; Thu, 23 Feb 2023 12:50:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B89113858C5E 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-f52.google.com with SMTP id j2so10415792wrh.9 for ; Thu, 23 Feb 2023 04:50:52 -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:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=olxt12RYOfLFOtQgzTnurBwXLqFY5ZjYvfkEL6uOqHM=; b=eGbQIFk7NsOtxN7jY5n3RbOJAiYud3ax6rOOcqAcvjpXMeOajZZfWtHt/Y2Q6DS1WO O3UEmwrym7CwstEYtVjd4K6dP251o0OGECFkNqsJBnDhfpecPsKtYgR7jetDNiTtvSBO zabNFOWBBBsLHzGpUQ7I61oP+Rm+wqyO9deDtmdfNxyvb1JNxTnKTC7xFmNTy+/yEYO3 qHTa47dapgCrSs/JamsMDVLkQW36a6jvTcxLy7XIsitUf6opJx8aNf78QPfbSh5CjQc2 D6D1q7/p9Uq5K28fjQj63m8p4/JxSqPekfrOjBpA3DR+okCwGJv2iPvvTqVYhLDavFR0 /idw== X-Gm-Message-State: AO0yUKUgEMhX6Rgn/mmC+1uVGf0dKsAenKX/ZXL5fPcXhOmHhhu6gO+O 5vBYMHHPVXftH3R+LdgNVU2KRmQdpKp0ug== X-Google-Smtp-Source: AK7set+uqiPfX1pykmooBDXBtUQVQcdh+o4e9HPyDz1f5tHTXLVxayKFhSm9ThOmvm9eW60s0Rr+uQ== X-Received: by 2002:adf:f707:0:b0:2c5:5984:6f07 with SMTP id r7-20020adff707000000b002c559846f07mr9351199wrp.26.1677156651276; Thu, 23 Feb 2023 04:50:51 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id t6-20020a5d4606000000b002c55306f6edsm13463763wrq.54.2023.02.23.04.50.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Feb 2023 04:50:50 -0800 (PST) Subject: Re: [PATCH v4 4/8] Python QUIT processing updates To: Kevin Buettner Cc: gdb-patches@sourceware.org References: <20230112015630.32999-1-kevinb@redhat.com> <20230112015630.32999-5-kevinb@redhat.com> <67d02aee-281d-5436-a969-90a3072867fe@palves.net> <20230219195233.10e5a0af@f37-zws-nv> From: Pedro Alves Message-ID: Date: Thu, 23 Feb 2023 12:50:48 +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: <20230219195233.10e5a0af@f37-zws-nv> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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=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: Hi Kevin, On 2023-02-20 2:52 a.m., Kevin Buettner wrote: > On Mon, 30 Jan 2023 19:01:16 +0000 > Pedro Alves wrote: > >> On 2023-01-12 1:56 a.m., Kevin Buettner wrote: >>> See the previous patches in this series for the motivation behind >>> these changes. >>> >>> This commit contains updates to Python's QUIT handling. Ideally, we'd >>> like to throw gdb_exception_forced_quit through the extension >>> language; I made an attempt to do this for gdb_exception_quit in an >>> earlier version of this patch, but Pedro pointed out that it is >>> (almost certainly) not safe to do so. >>> >>> Still, we definitely don't want to swallow the exception representing >>> a SIGTERM for GDB, nor do we want to force modules written in the >>> extension language to have to explicitly handle this case. Since the >>> idea is for GDB to cleanup and quit for this exception, we'll simply >>> call quit_force() just as if the gdb_exception_forced_quit propagation >>> had managed to make it back to the top level. >>> >>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761 >> >> I guess this is OK as long as we don't hook up Python at a very low level >> where running quit_force() would be dangerous. >> >> Alternatively, couldn't we force some Python exception/error which >> is not catch-able from Python code? Set some error flag in the >> Python interpreter or something, so that it aborts the Python code >> as soon as we return to the Python interpreter. We'd use the >> set_quit_flag() trick here where you're calling quit_force (and >> instead of calling quit_force), so that as soon as we get out of the >> Python interpreter on the other end, we'd re-raise >> gdb_exception_forced_quit. > > I've looked into doing this, but I haven't found a way to force/throw > an uncatchable Python error or exception. Thanks for checking. I was hoping that we could at least do something like calling something like Py_Finalize() from within a Python callback, but of course a version of that function that signaled that were bringing down the interpreter, without causing Python to crash as soon as we're out of the callback back into Python. > > We could define a Python exception, say GDBForcedQuitException, that's > derived from BaseException, but it can still be caught either via: > > try: > ... > except GDBForcedQuitException: > ... > > Or: > > try: > ... > except BaseException: > ... > > Or even: > > try: > ... > except: > ... > > The latter construct will basically catch everything. This is why > there are no uncatchable exceptions (or errors) in Python. That said, > deriving GDBForcedQuitException from BaseException (instead of Exception) > means that it can't be caught via "except Exception:", which is a catch-all > for normal exceptions. > > I also took a look at calling PyErr_SetInterruptEx (SIGTERM) which > would simulate the effect of the Python layer receiving a SIGTERM > signal. For Ctrl-C/SIGINT, We use something similar - a call to > PyErr_SetInterrupt() which is equivalent to PyErr_SetInterruptEx(SIGINT). > However, for SIGINT, python defines the default signal handler for > SIGINT to raise the KeyboardInterrupt exception. However, from my > reading of the documentation, Python doesn't have a default handler > for SIGTERM. The documentation says that such signals will be ignored. > > Even though it's not uncatchable, it might be worth pursuing your > idea via an exception derived from BaseException as described above. > I started looking into this, but doing it looks somewhat involved. > So, instead of including it in this series, I'd prefer to push this > commit as-is and work on raising a GDBForcedQuitException in a separate > series. Yes, let's do that. Thanks again for the investigation.