Python gdb C backtrace interpretation for async callbacks


How does one make a meaningful interpretation of a gdb C backtrace, for python plugin loaded via libpeas for a GNOME app ?

Example backtrace at:

The above backtrace is a hang bug due to blocking glibc network function call __libc_connect, caused by a python3 plugin loaded via libpeas in Rhythmbox.

This specific backtrace is the easy part, where libpeas loads the plugin, so there is some information on what plugin is causing the hang / crash. But, assume the same network connection function call ( __libc_connect ), in the above backtrace was through an GLib async callback, much later in the life-cycle of the plugin. In that case, there is no information specific to the plugin in the entire backtrace ( at least AFAIK ).

So, how does one identify the offending python plugin causing a hang / crash in such a case ?

Thanks !

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.