New submission from Maxwell Ballenger :
I have been working on debugging a segfault. When faulthandler catches the
fault, it makes a printout like this:
Current thread 0x7f4fa62b2700 (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
<https://bugs.python.org/issue44466>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
