Skip to content

GDB extensions fails with optimized 3.13 due to cframe removal #127147

Closed
Closed
GDB extensions fails with optimized 3.13 due to cframe removal#127147
Labels
3.13only security fixes3.14bugs and security fixestriagedThe issue has been accepted as valid by a triager.type-bugAn unexpected behavior, bug, or error

Description

@kasium
kasium
opened on Nov 22, 2024

Bug report

Bug description:

When using the python gdb extention python-gdb.py on an optimized python 3.13 installation, gdb shows no backtrace:

Reading symbols from .pyenv/versions/3.13.0/bin/python...
Attaching to program: .pyenv/versions/3.13.0/bin/python, process 53537
Reading symbols from .pyenv/versions/3.13.0/lib/libpython3.13.so.1.0...
Reading symbols from /lib64/libpthread.so.0...
(No debugging symbols found in /lib64/libpthread.so.0)
Reading symbols from /lib64/libdl.so.2...
(No debugging symbols found in /lib64/libdl.so.2)
Reading symbols from /lib64/libutil.so.1...
(No debugging symbols found in /lib64/libutil.so.1)
Reading symbols from /lib64/libm.so.6...
(No debugging symbols found in /lib64/libm.so.6)
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/readline.cpython-313-x86_64-linux-gnu.so...
Reading symbols from /lib64/libreadline.so.7...
(No debugging symbols found in /lib64/libreadline.so.7)
Reading symbols from /lib64/libtinfo.so.6...
(No debugging symbols found in /lib64/libtinfo.so.6)
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/_opcode.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/unicodedata.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/select.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/_struct.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/termios.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/fcntl.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/_curses.cpython-313-x86_64-linux-gnu.so...
Reading symbols from /lib64/libncursesw.so.6...
(No debugging symbols found in /lib64/libncursesw.so.6)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f798865ea53 in poll () from /lib64/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-150300.89.2.x86_64 libncurses6-debuginfo-6.1-150000.5.27.1.x86_64 libreadline7-debuginfo-7.0-150400.27.3.2.x86_64
(gdb) py-bt
Traceback (most recent call first):
  (unable to read python frame information)
  <built-in method exec of module object at remote 0x7f7988499800>
  (unable to read python frame information)

If the same setup is used but python is compiled in non-optimized mode (just don't set the CC and PYTHON_CONFIGURE_OPTS env variable), the backtrace works as expected. Same applies for python 3.12 and lower

Reading symbols from .pyenv/versions/3.13.0/bin/python...
Attaching to program: .pyenv/versions/3.13.0/bin/python, process 79951
Reading symbols from .pyenv/versions/3.13.0/lib/libpython3.13.so.1.0...
Reading symbols from /lib64/libpthread.so.0...
(No debugging symbols found in /lib64/libpthread.so.0)
Reading symbols from /lib64/libdl.so.2...
(No debugging symbols found in /lib64/libdl.so.2)
Reading symbols from /lib64/libutil.so.1...
(No debugging symbols found in /lib64/libutil.so.1)
Reading symbols from /lib64/libm.so.6...
(No debugging symbols found in /lib64/libm.so.6)
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/readline.cpython-313-x86_64-linux-gnu.so...
Reading symbols from /lib64/libreadline.so.7...
(No debugging symbols found in /lib64/libreadline.so.7)
Reading symbols from /lib64/libtinfo.so.6...
(No debugging symbols found in /lib64/libtinfo.so.6)
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/_opcode.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/unicodedata.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/select.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/_struct.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/termios.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/fcntl.cpython-313-x86_64-linux-gnu.so...
Reading symbols from .pyenv/versions/3.13.0/lib/python3.13/lib-dynload/_curses.cpython-313-x86_64-linux-gnu.so...
Reading symbols from /lib64/libncursesw.so.6...
(No debugging symbols found in /lib64/libncursesw.so.6)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007f947f668a53 in poll () from /lib64/libc.so.6
--Type <RET> for more, q to quit, c to continue without paging--
Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-150300.89.2.x86_64 libncurses6-debuginfo-6.1-150000.5.27.1.x86_64 libreadline7-debuginfo-7.0-150400.27.3.2.x86_64
(gdb) py-bt
Traceback (most recent call first):
  File ".pyenv/versions/3.13.0/lib/python3.13/_pyrepl/unix_console.py", line 426, in wait
    or bool(self.pollob.poll(timeout))
  File ".pyenv/versions/3.13.0/lib/python3.13/_pyrepl/reader.py", line 756, in handle1
    self.console.wait(100)
  File ".pyenv/versions/3.13.0/lib/python3.13/_pyrepl/reader.py", line 801, in readline
    self.handle1()
  File ".pyenv/versions/3.13.0/lib/python3.13/_pyrepl/readline.py", line 389, in multiline_input
    return reader.readline()
  File ".pyenv/versions/3.13.0/lib/python3.13/_pyrepl/simple_interact.py", line 151, in run_multiline_interactive_console
    statement = multiline_input(more_lines, ps1, ps2)
  File ".pyenv/versions/3.13.0/lib/python3.13/_pyrepl/main.py", line 59, in interactive_console
    run_multiline_interactive_console(console)
  File ".pyenv/versions/3.13.0/lib/python3.13/_pyrepl/__main__.py", line 6, in <module>
    __pyrepl_interactive_console()
  <built-in method exec of module object at remote 0x7f947f4a5800>
  File "<frozen runpy>", line 88, in _run_code
  File "<frozen runpy>", line 198, in _run_module_as_main

Steps to reproduce

  1. install pyenv incl. all OS packages which are needed
  2. install gcc12
  3. export CC="gcc-12"
  4. export PYTHON_CONFIGURE_OPTS="--enable-shared --with-lto --enable-optimizations"
  5. pyenv install 3.13.0
  6. Open a new python3.13 shell using the just installed python and execute the following commands
    6.1. import os
    6.2. os.getpid()
    6.3. while True: pass
  7. Switch to another shell and execute gdb -q <path-to-pyenv>/versions/3.13.0/bin/python -p <pid>
  8. Wait till gdb spins up and execute py-bt

OS: SUSE Linux Enterprise Server 15 SP4

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Activity

  1. kasium
    added
    type-bugAn unexpected behavior, bug, or error
    on Nov 22, 2024
  2. kasium
    changed the title [-]python 3.13 gdb extension does not work with optimized build[/-] [+]GDB extensions fails with optimized 3.13 due to cframe removal[/+] on Jan 9, 2025

  3. kasium commented on Jan 9, 2025

    @kasium
    kasium
    on Jan 9, 2025
    Author

    I had now some time to dig into this issue further. It happens in the python3.13-gdb.py file within the following code

        def get_pyop(self):
        try:
            frame = self._gdbframe.read_var('frame')
            frame = PyFramePtr(frame)
            if not frame.is_optimized_out():
                return frame
            cframe = self._gdbframe.read_var('cframe')
            if cframe is None:
                return None
            frame = PyFramePtr(cframe["current_frame"])
            if frame and not frame.is_optimized_out():
                return frame
            return None
        except ValueError:
            return None

    With an optimized build, the first if evaluates to false, so that the code tries to read cframe. This variable was removed with #108036 so there needs to be some fix which changes the usage of cframe to the successor

  4. picnixz
    added
    triagedThe issue has been accepted as valid by a triager.
    3.13only security fixes
    3.14bugs and security fixes
    on Feb 10, 2025

  5. picnixz commented on Feb 10, 2025

    @picnixz
    picnixz
    on Feb 10, 2025
    Member

    cc @gaogaotiantian (are you the relevant expert here?)

  6. gaogaotiantian commented on Feb 10, 2025

    @gaogaotiantian
    gaogaotiantian
    on Feb 10, 2025
    Member

    I have basically 0 knowledge of that file. @markshannon has touched that one a few times I believe but not sure if he is the expert either. He is the expert on the cframe overall however. I can try to take a look if he's too busy.

  7. markshannon commented on Feb 11, 2025

    @markshannon
    markshannon
    on Feb 11, 2025
    Member

    The reference to cframe is clearly wrong, we should remove that.

    It looks like the gdb extension for 3.13 needs debug symbols to work.
    The exact behavior of the gdb plugin is neither tested or documented, it is just a "best effort".
    The docs say only that a debug build is recommended, not required for debugging, so maybe we should treat this as a bug?

    If it worked for 3.12, it would be nice if it worked for 3.13 and 3.14.

  8. cielavenir commented on Dec 3, 2025

    @cielavenir
    cielavenir
    on Dec 3, 2025

    In #142095 (comment) @mpage showed updated implementation using _Py_tss_gilstate but (1) _Py_tss_gilstate is Py3.15 only, Py3.14 can cherry-pick b8998fe but not sure if libpython3.14 ABI is compatible (2) Py3.13 is not compatible (cherry-pick causes conflict)

  9. cielavenir commented on Jan 9, 2026

    @cielavenir
    cielavenir
    on Jan 9, 2026

    @colesbury can this be closed as well?

  10. colesbury
    closed this as completedon Jan 9, 2026

  11. colesbury commented on Jan 9, 2026

    @colesbury
    colesbury
    on Jan 9, 2026
    Contributor

    yes, thanks

  12. kasium commented on Jan 12, 2026

    @kasium
    kasium
    on Jan 12, 2026
    Author

    Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.13only security fixes3.14bugs and security fixestriagedThe issue has been accepted as valid by a triager.type-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions