> 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: https://stackoverflow.com/questions/979141/how-to-programmatically-cause-a-core-dump-in-c-c

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.