Python GDB scripts for Fedora41

[voidtrance]

Hi, this might be a long shot and may not fall in the python coding help category exactly but I can't find any other information about it.

I am trying to get the Python GDB scripts setup on my system so I can get access to py-bt, py-list, etc.

I am running Fedora 41 with Python3.13. I have installed python3-3.13.2-1.fc41.x86_64, python3.13-debuginfo-3.13.1-2.fc41.x86_64, and python3.13-debugsource-3.13.1-2.fc41.x86_64 but none of those RPMs provide python3-gdb.py or python3.13-gdb.py

I do see /usr/lib/debug/usr/lib64/libpython3.13.so.1.0-3.13.1-2.fc41.x86_64.debug-gdb.py and /usr/lib/debug/usr/lib64/libpython3.13d.so.1.0-3.13.1-2.fc41.x86_64.debug-gdb.py, however, it doesn't seem like gdb is trying to load those. Most likely, this is because on my system /usr/bin/python3.13d is not linked against /usr/lib64/libpython3.13d.so.1.0 but rather /lib64/libpython3.13d.so.1.0.

This is my .gdbinit file:

set debuginfod enabled on
add-auto-load-safe-path /usr/share/gdb/python/gdb/
add-auto-load-safe-path /usr/lib/debug/
set auto-load python-scripts on
set auto-load gdb-scripts on

Any help with this is appreciated.

[Gribouillis]

Not a Fedora user here but the Python documentation suggests that you issue the following commands for Fedora

Output:
sudo dnf install gdb
sudo dnf debuginfo-install python3

Have you done this step?

[snippsat]

The key issue seems to be the mismatch between where your Python binary expects to find the library (/lib64/) and where the debug scripts are configured (/usr/lib64/).
One straightforward fix is to create a symbolic link so that the path GDB looks in actually points to the real location.
For example, you can make GDB’s expected directory match by linking:

sudo ln -s /usr/lib/debug/usr/lib64 /usr/lib/debug/lib64

After doing this,when GDB looks in /usr/lib/debug/lib64/,
it should find the auto-load scripts (since they appear via the symlink) and load the Python commands.

Alternatively, you can tell GDB where to look by setting its debug-file-directory.
In your .gdbinit file (or at the GDB prompt) add a line like:

set debug-file-directory /usr/lib/debug/usr/lib64:/usr/lib/debug

This tells GDB to check both paths when searching for debug files

[voidtrance]

The key issue seems to be the mismatch between where your Python binary expects to find the library (/lib64/) and where the debug scripts are configured (/usr/lib64/).
One straightforward fix is to create a symbolic link so that the path GDB looks in actually points to the real location.
For example, you can make GDB’s expected directory match by linking:

sudo ln -s /usr/lib/debug/usr/lib64 /usr/lib/debug/lib64

After doing this,when GDB looks in /usr/lib/debug/lib64/,
it should find the auto-load scripts (since they appear via the symlink) and load the Python commands.

Alternatively, you can tell GDB where to look by setting its debug-file-directory.
In your .gdbinit file (or at the GDB prompt) add a line like:

set debug-file-directory /usr/lib/debug/usr/lib64:/usr/lib/debug

This tells GDB to check both paths when searching for debug files

On my system /usr/lib/debug/lib64 is a link to /usr/lib/debug/usr/lib64/ so that's not it.

total 16
drwxr-xr-x. 1 root root   62 Jan 17 08:31 .
dr-xr-xr-x. 1 root root 1148 Mar  7 12:58 ..
lrwxrwxrwx. 1 root root    7 Apr 13  2023 bin -> usr/bin
drwxr-xr-x. 1 root root  736 Jan 17 08:31 .build-id
drwxr-xr-x. 1 root root   62 Jan 17 08:31 .dwz
lrwxrwxrwx. 1 root root    7 Apr 13  2023 lib -> usr/lib
lrwxrwxrwx. 1 root root    9 Apr 13  2023 lib64 -> usr/lib64
lrwxrwxrwx. 1 root root    8 Apr 13  2023 sbin -> usr/sbin
drwxr-xr-x. 1 root root   38 Dec  8 16:00 usr

What I am seeing is that GDB doesn't even seem to be looking for debug info for libpython. It only looks for python3.13d and since there is no GDB scripts file for that executable, it's not loading anything. The only things I see in /usr/lib/debug/usr/bin are:

total 64
drwxr-xr-x. 1 root root   304 Jan 17 08:31 .
drwxr-xr-x. 1 root root    38 Dec  8 16:00 ..
-r--r--r--. 1 root root 15624 Dec  8 16:00 python3.13-3.13.1-2.fc41.x86_64.debug
-r--r--r--. 1 root root 15344 Dec  8 16:00 python3.13d-3.13.1-2.fc41.x86_64.debug
-r--r--r--. 1 root root 15632 Dec  8 16:00 python3.13t-3.13.1-2.fc41.x86_64.debug
-r--r--r--. 1 root root 15360 Dec  8 16:00 python3.13td-3.13.1-2.fc41.x86_64.debug

If I create a symlink like this:

lrwxrwxrwx. 1 root root    64 Apr 14 11:05 python3.13d-gdb.py -> ../lib64/libpython3.13d.so.1.0-3.13.1-2.fc41.x86_64.debug-gdb.py

everything loads correctly and I have all of the Python GDB scripts.

[RokeJulianLockhart]

I've experienced this (in Fedora 43), too. I've detailed my environment at discussion.fedoraproject.org/t/179757. I'm posting here to ask whether this amount of manual configuration is expected, or whether I should err on this being a packaging bug.

[Pedroski55]

Doesn't Python already have enough built in debugging for you? Why do you need GNU debugging on top?

# fetch some data
data = bt.get('spy,agg', start='2010-01-01')
print(data.head())

This looks a lot like pandas to me:

Output:
                   spy        agg
 Date
 2010-01-04  89.225410  74.942825
 2010-01-05  89.461586  75.283791
 2010-01-06  89.524574  75.240227
 2010-01-07  89.902473  75.153221
 2010-01-08  90.201691  75.196724

[bowlofred]

Doesn't Python already have enough built in debugging for you? Why do you need GNU debugging on top?

It can be really handy in some cases.

Imagine you have a production web server running a python application. It runs hundreds of thousands of requests daily (successfully). Then every once in a while it locks up hard, no logging, no response. You restart the server and it immediately locks up again. For a large program it may be difficult to understand exactly where things are happening. Adding logging could help, but only if you've already got some ideas. Increasing logging 100-fold might be too expensive if the error is rare.

With everything configured properly, you can open the hung server in gdb and inspect where the python code is currently running.