-
-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
faulthandler should indicate if the fault happened in garbage collection #88632
Comments
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): 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! |
faulthandler has no access to the C-stack so it cannot see the gc_collect_main() as gdb does. |
Maxwell: Oh, that's a good idea! I wrote PR 26823 to implement the feature. It's just 3 new lines in traceback.c :-) if (tstate == current_tstate && tstate->interp->gc.collecting) {
PUTS(fd, " Garbage-collecting\n");
} |
Maxwell: That was a nice idea and it's now added to Python 3.10 (will be part of the next Python 3.10 beta release)! I got an exception to land this feature in Python 3.10 even if we are past the feature freeze (see PR 26823 discussion). As explained in PR 26823, Py_FatalError() also gets this _Py_DumpTracebackThreads() enhancement ;-) See an example at: |
Thank you Victor, sounds great! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: