[PATCH] gdb/python: initialize Python without signal handlers

[PATCH] gdb/python: initialize Python without signal handlers

[Alexey Lapshin]

Fix embedded Python initialization.
Installing signal handlers on Windows GDB builds might lead to issues
---
 gdb/python/python.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gdb/python/python.c b/gdb/python/python.c
index 29f2010ee8e..833eedd35f9 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -2050,7 +2050,7 @@ do_start_initialization ()
      remain alive for the duration of the program's execution, so
      it is not freed after this call.  */
   Py_SetProgramName (progname_copy);
-  Py_Initialize ();
+  Py_InitializeEx (0);
 #else
   PyConfig config;
 
@@ -2062,6 +2062,7 @@ do_start_initialization ()
 
   config.write_bytecode = python_write_bytecode ();
   config.use_environment = !python_ignore_environment;
+  config.install_signal_handlers = 0;
 
   status = PyConfig_Read (&config);
   if (PyStatus_Exception (status))
@@ -2075,7 +2076,7 @@ do_start_initialization ()
     return false;
 #endif
 #else
-  Py_Initialize ();
+  Py_InitializeEx (0);
 #endif
 
 #if PY_VERSION_HEX < 0x03090000
-- 
2.34.1

Re: [PATCH] gdb/python: initialize Python without signal handlers

[Tom Tromey]

>>>>> "Alexey" == Alexey Lapshin via Gdb-patches <gdb-patches@sourceware.org> writes:

Alexey> Fix embedded Python initialization.
Alexey> Installing signal handlers on Windows GDB builds might lead to issues

Could you say what these issues are and why it's desirable to make this
change for all hosts?

Tom

Re: [PATCH] gdb/python: initialize Python without signal handlers

[Alexey Lapshin]

> 
> Could you say what these issues are and why it's desirable to make
> this
> change for all hosts?

The issues related to signal handlings. For Windows builds CTRL+C does
not work. Because it handles by Pyhton, not a GDB.
I don't know why it does not happen on Linux builds, but I believe that
signal handlers must not be set.
Also, documentation
(https://sourceware.org/gdb/onlinedocs/gdb/Basic-Python.html) says:

> If your program changes the handling of these signals, GDB will most
likely stop working correctly.

So, there is no reason to set default Python signal handlings that
could differ from version to version
And it's better to handle all signals in GDB itself, not in third-party
libraries

Regards,
Alexey

Re: [PATCH] gdb/python: initialize Python without signal handlers

[Tom Tromey]

>> Could you say what these issues are and why it's desirable to make
>> this change for all hosts?

Alexey> The issues related to signal handlings. For Windows builds CTRL+C does
Alexey> not work.

We fixed this a different way.

Alexey> So, there is no reason to set default Python signal handlings
Alexey> that could differ from version to version And it's better to
Alexey> handle all signals in GDB itself, not in third-party libraries

This makes sense but I wonder if there are other impacts from this
change that we wouldn't want.  For example, if it affects Python scripts
running in gdb.

Tom

Re: [PATCH] gdb/python: initialize Python without signal handlers

[Alexey Lapshin]

> We fixed this a different way.
Could you please give a commit hash?

> For example, if it affects Python scripts

I don't think that will break anything, because Python only sets
SIGPIPE, SIGXFZ, SIGXFSZ signals to ignore
(https://github.com/python/cpython/blob/0e081a089ec969c9a34f5ff25886205616ef4dd3/Modules/signalmodule.c#L1910-L1918
). And sets SIGINT signal handler, which is not using. Because POSIX
standard declares that only one signal handler could be set for a
signal. We know that Python SIGINT-handler is not using in GDB for
linux because we could not stop debugging applications otherwise.

I just wanted to init Python properly. See also a comment in Python
source code. It also is not strictly related to this patch, but could
be interesting for
you. https://github.com/python/cpython/blob/135ec7cefbaffd516b77362ad2b2ad1025af462e/Python/pythonrun.c#L1680-L1687

Regards,
Alexey