[Bug gdb/25297] New: Segmentation fault when using Python 3.8 gdb.execute on target extended-remote

narwhalx42 at gmail dot com sourceware-bugzilla@sourceware.org
Thu Dec 19 14:22:00 GMT 2019


            Bug ID: 25297
           Summary: Segmentation fault when using Python 3.8 gdb.execute
                    on target extended-remote
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: narwhalx42 at gmail dot com
  Target Milestone: ---

When debugging remotely using gdbserver and gdb the use of CTR-C after a python
gdb.execute command leads to a segmentation fault in GDB.

How to recreate the problem:
I used a small C program that performs an infinite loop printing something
every second called `testcase`

1) Start the gdbserver:
$ gdbserver :2345 testcase

2) Connect GDB and execute a Python command:
$ gdb -ex "target extended-remote :2345" -ex "python gdb.execute('c')" testcase

3) Press CTRL-C. GDB will crash with a segmentation fault. (see below for the
Valgrind output of the crash).

This *could* be a Python bug, as this happens since Python 3.8 and the
segmentation fault is generated in the Python source code, there in `is_main()`
in `signalmodule.c` the macro `_PyRuntimeState_GetThreadState` returns a NULL
pointer which is used.

This was introduced in this commit to CPython

I am posting this here, as it might be a bug related to the API usage? I am not
familiar with the GDB code base and I also don't know anything about
integrating Python as a library inside another application such as GDB. I hope
someone here can help me get to the root of the problem, or tell me if I should
go submit a CPython bug report.

Valgrind crash output after the segmentation fault:
==438665==    at 0x48D21F2: is_main (signalmodule.c:196)
==438665==    by 0x48D660B: PyOS_InterruptOccurred (signalmodule.c:1736)
==438665==    by 0x34EA55: check_quit_flag() (extension.c:829)
==438665==    by 0x3486A8: default_quit_handler() (event-top.c:991)
==438665==    by 0x346E91: invoke_async_signal_handlers() (event-loop.c:973)
==438665==    by 0x347978: gdb_do_one_event() (event-loop.c:303)
==438665==    by 0x52F7FB: wait_sync_command_done() (top.c:523)
==438665==    by 0x52FCC4: maybe_wait_sync_command_done (top.c:540)
==438665==    by 0x52FCC4: execute_command(char const*, int) (top.c:654)
==438665==    by 0x2ADD1A: execute_control_command_1(command_line*, int)
==438665==    by 0x2AE0F1: execute_control_commands(command_line*, int)
==438665==    by 0x4811CC: execute_gdb_command(_object*, _object*, _object*)
==438665==    by 0x495EBA5: cfunction_call_varargs (call.c:742)
==438665==  Address 0x10 is not stack'd, malloc'd or (recently) free'd

Version info:
GNU gdb (GDB)
Python 3.8.0

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Gdb-prs mailing list