STINNER Victor added the comment: > 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. ---------- resolution: wont fix -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30998> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
