public inbox for
 help / color / mirror / Atom feed
From: Kevin Buettner <>
To: Pedro Alves <>
Subject: Re: [PATCH v4 4/8] Python QUIT processing updates
Date: Sun, 19 Feb 2023 19:52:33 -0700	[thread overview]
Message-ID: <20230219195233.10e5a0af@f37-zws-nv> (raw)
In-Reply-To: <>

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:  
> 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:

    except GDBForcedQuitException:


    except BaseException:

Or even:


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


  reply	other threads:[~2023-02-20  9:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-12  1:56 [PATCH v4 0/8] Fix gdb.base/gdb-sigterm.exp failure/error Kevin Buettner
2023-01-12  1:56 ` [PATCH v4 1/8] Introduce gdb_exception_forced_quit Kevin Buettner
2023-01-30 18:56   ` Pedro Alves
2023-01-12  1:56 ` [PATCH v4 2/8] Handle gdb SIGTERM by throwing / catching gdb_exception_force_quit Kevin Buettner
2023-01-30 18:57   ` Pedro Alves
2023-01-12  1:56 ` [PATCH v4 3/8] Catch gdb_exception_error instead of gdb_exception (in many places) Kevin Buettner
2023-01-30 19:00   ` Pedro Alves
2023-02-16 10:52     ` Pedro Alves
2023-01-12  1:56 ` [PATCH v4 4/8] Python QUIT processing updates Kevin Buettner
2023-01-30 19:01   ` Pedro Alves
2023-02-20  2:52     ` Kevin Buettner [this message]
2023-02-23 12:50       ` Pedro Alves
2023-01-12  1:56 ` [PATCH v4 5/8] Guile " Kevin Buettner
2023-01-12  1:56 ` [PATCH v4 6/8] Call quit_force for gdb_exception_forced_quit in safe_execute_command Kevin Buettner
2023-01-30 19:01   ` Pedro Alves
2023-01-12  1:56 ` [PATCH v4 7/8] QUIT processing w/ explicit throw for gdb_exception_forced_quit Kevin Buettner
2023-01-30 19:02   ` Pedro Alves
2023-01-12  1:56 ` [PATCH v4 8/8] Forced quit cases handled by resetting sync_quit_force_run Kevin Buettner
2023-01-30 19:02   ` Pedro Alves
2023-01-12 12:37 ` [PATCH v4 0/8] Fix gdb.base/gdb-sigterm.exp failure/error Tom de Vries
2023-01-27 22:03   ` Kevin Buettner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230219195233.10e5a0af@f37-zws-nv \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).