This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients The Compiler, ammar2, vstinner
Date 2017-07-24.09:49:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> While faulthandler's output is already quite useful when dealing with crashes in C libraries, it'd be much more useful when it could also show a low-level C/C++ stack.

It's a deliberate choice to not read the "C" backtrace: it requires complex non-portable libraries. faulthandler has a "simple" design, but the implementation is non trivial especially because it is designed to be async-signal-safe (no malloc, no printf, no lock, etc.).

faulthandler design is to read global Python internal structures and dumps them on stderr. The code is as portable as Python is: faulthandler works on all platforms! There are only tiny limitations on Windows on faulthandler.register(), but IMHO the main usage of faulthandler is to dump Python tracebacks on a crash and that works on Windows as well. By the way, I recently added support to Windows exceptions, so it uses better Windows native APIs.

You *can* write a Python module which depends on a specific library and only works on a limited set of platforms. But such module belongs to PyPI, I consider that it shouldn't be part of the Python stdlib. Usually, Python avoids dependencies whenever possible. Again, to get the maximum portability.

> As much as I like this idea I don't think implementing is going to be possible and this is one of the points where you just have to attach a debugger like gdb for good information.

While it's "nice" to have a "C" traceback, I also prefer to get a debugger like gdb to inspect more data: variables, registers, threads, etc.

> Maybe it would be useful to have an option to say always generate a core dump? Something like the stuff listed here:

10 years ago, it was common to dump cores in the current directory. Nowadays, operating systems provide a program which collects core dumps, send them to a server to get a reliable stacktrace, automatically open a bug report, etc. Getting a core dump requires to configure your operating system.

I'm not a big fan of coredump. Coredumps are not portable at all. Don't try to open a Ubuntu coredump on Fedora. I wouldn't even try to open a Fedora 25 coredump on Fedora 26.

On Linux, changing how where and how coredumps are written requires to be a root user. You may want to support coredumpctl, etc.

Again, it's a complex task and it's hard to get a portable behaviour.

If someone is interested to get this feature, please create a small project on PyPI. Come back later when you get enough user feedback and supports enough platforms to consider that it can be added to Python stdlib.
Date User Action Args
2017-07-24 09:49:22vstinnersetrecipients: + vstinner, The Compiler, ammar2
2017-07-24 09:49:22vstinnersetmessageid: <>
2017-07-24 09:49:22vstinnerlinkissue30998 messages
2017-07-24 09:49:21vstinnercreate