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-porta
Ammar Askar added the comment:
No need to close it off just yet, what I posted was just my opinion. We can
wait for haypo's expert opinion seeing as he implemented faulthandler.
Maybe it would be useful to have an option to say always generate a core dump?
Something like the stuff listed here
Florian Bruhin added the comment:
Hmm, fair point. I thought I had seen this being used in a SEGV handler in some
other software I use, but I can't find that anymore - so either I was dreaming,
or they noticed it was problematic and removed it again.
I'm closing this then. My goal was to get m
Ammar Askar added the comment:
As the faulthandler documentation notes:
> The fault handler is called on catastrophic cases and therefore can only use
> signal-safe functions (e.g. it cannot allocate memory on the heap). Because
> of this limitation traceback dumping is minimal compared to no
New submission from Florian Bruhin:
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.
glibc has functions to do that:
https://www.gnu.org/software/libc/manual/html_node/Backtr
