Re: [PATCH v5 0/8] Fix gdb.base/gdb-sigterm.exp failure/error

Pedro Alves
2023-02-23T13:01:22Z

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@palves.net>

Pedro Alves