From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 230E6394D827 for ; Mon, 20 Feb 2023 09:56:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 230E6394D827 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676886972; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mJCFnJ9jJJcEGKFkCGGUEdnZwvJAdNwkgXSBX+vG4H0=; b=L/UyZaifTAOJDj2GrGK2QWDijeCBDTQXNx9QwJjr8dNeJpxgiuAGjv+Qkitn3J5ylXop1G 2OsyhATjy3yWdZpITcxjOSoGysMUkgno/TeblvgJLtmGfWimB25hwGLyVeXj/wpHf2RiuR b+Na8gA0uuUEGqK109vLesTnmIzeOX0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-639-8TA9q-21OAWyiEVvUG3D0A-1; Sun, 19 Feb 2023 21:52:42 -0500 X-MC-Unique: 8TA9q-21OAWyiEVvUG3D0A-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CB15A85A5B1; Mon, 20 Feb 2023 02:52:41 +0000 (UTC) Received: from f37-zws-nv (unknown [10.2.16.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8704A492B00; Mon, 20 Feb 2023 02:52:41 +0000 (UTC) Date: Sun, 19 Feb 2023 19:52:33 -0700 From: Kevin Buettner To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v4 4/8] Python QUIT processing updates Message-ID: <20230219195233.10e5a0af@f37-zws-nv> In-Reply-To: <67d02aee-281d-5436-a969-90a3072867fe@palves.net> References: <20230112015630.32999-1-kevinb@redhat.com> <20230112015630.32999-5-kevinb@redhat.com> <67d02aee-281d-5436-a969-90a3072867fe@palves.net> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. 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. Kevin