Old title: Added a segfault handler which is active during python execution to print a python backtrace on segfault
When users run into problems such as the one described in T77038, Blender will crash, and will write some not-particularly-helpful information to a file.
In this scenario, some user python code has caused blender to crash because the user has written some bad code that causes blender to segfault.
When this happens, it is very tricky for the user to isolate exactly where the problem is in their python code. I want to fix this.
This patch adds a segfault handler that can print a python backtrace upon a segfault, which makes it much easier for the user to find the problem in their code.
Ideally, I would like this to be presented to the user in a small dialog window when the crash happens, but for now it just prints it to stderr.
Previously I would get this output on a segfault:
Writing: /tmp/test_segfault.crash.txt fish: “../build_linux_debug/bin/blender” terminated by signal SIGSEGV (Address boundary error) daniel@dan-l13 ~/b/blender (master) [SIGSEGV]>
This patch enables me now to have some clue of where the problem occurred, as it prints this instead:
Segfault at 0x70 during execution of python code. This could be either a blender bug or a user-provided python bug. Stack trace (most recent call first): File "/home/daniel/Downloads/test_segfault.blend/test.py", line 16 in handler Writing: /tmp/test_segfault.crash.txt fish: “../build_linux_debug/bin/blender” terminated by signal SIGSEGV (Address boundary error) daniel@dan-l13 ~/b/blender (master) [SIGSEGV]>