[issue44466] faulthandler should indicate if the fault happened in garbage collection

Maxwell Ballenger report at bugs.python.org
Sun Jun 20 16:24:28 EDT 2021


New submission from Maxwell Ballenger <ballengerm at gmail.com>:

I have been working on debugging a segfault. When faulthandler catches the fault, it makes a printout like this:

Current thread 0x00007f4fa62b2700 (most recent call first):
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 919, in call_at
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 502, in add_timeout
  ...

However, when I run the same app with gdb, catch the segfault with gdb and and run py-bt, it makes a printout like this

(gdb) py-bt
Traceback (most recent call first):
  Garbage-collecting
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 919, in call_at
    functools.partial(stack_context.wrap(callback), *args, **kwargs),
  File "/usr/lib/python3.6/site-packages/tornado/ioloop.py", line 502, in add_timeout
    return self.call_at(deadline, callback, *args, **kwargs)
  ...

The important distinction here for me is the "Garbage-collecting" line. When debugging this issue with faulthandler, I thought that the segfault was happening somewhere in the execution stack of this ioloop.py function. It wasn't until I ran under gdb that I realized it was actually happening in garbage collection and more or less has nothing to do with ioloop.py. It seems like faulthandler should be able to tell that the segfault was actually generated in garbage collection and this would make faulthandler much more helpful for cases like this.

Thank you for reading!

----------
components: Library (Lib)
messages: 396196
nosy: maxballenger
priority: normal
severity: normal
status: open
title: faulthandler should indicate if the fault happened in garbage collection
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue44466>
_______________________________________


More information about the Python-bugs-list mailing list