gdb/python: initialize Python without signal handlers

Message ID 046071702889c1a0bb4fe33df605e865b5df571c.camel@espressif.com
State New
Headers
Series gdb/python: initialize Python without signal handlers |

Commit Message

Alexey Lapshin Nov. 9, 2022, 7:42 p.m. UTC
  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(-)

-- 
2.34.1
  

Comments

Tom Tromey Nov. 9, 2022, 8:12 p.m. UTC | #1
>>>>> "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
  
Alexey Lapshin Nov. 9, 2022, 8:40 p.m. UTC | #2
> 
> 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
  
Tom Tromey Dec. 20, 2022, 8:24 p.m. UTC | #3
>> 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
  
Alexey Lapshin Dec. 21, 2022, 4:12 p.m. UTC | #4
> 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
  

Patch

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