Any way to ask faulthandler to also trap SIGTRAP?

[mgedmin]

The reason I ask is that I'm debugging a Python app that uses GTK+ (via pygobject), and I can ask it to abort on any warnings by passing --g-fatal-warnings. Unfortunately this produces a SIGTRAP which kills my program without displaying the stack when I do

$ python3 -Xfaulthandler ./gtimelog --g-fatal-warnings

(gtimelog:1663): Gtk-WARNING **: Allocating size to  0x12fa320 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Trace/breakpoint trap (core dumped)

[exited with 133]

[mgedmin]

Here's a stack trace from gdb (without debug symbols):

#0  0x00007ffff51f0a6b in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007ffff51f0bdf in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fffed857348 in gtk_widget_size_allocate_with_baseline () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#3  0x00007fffed867c8f in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x00007ffff54c11d4 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x00007ffff54db9a6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x00007ffff54dc08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x00007fffed647b48 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#8  0x00007ffff54c11d4 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#9  0x00007ffff54db9a6 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#10 0x00007ffff54dc08f in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x00007ffff381851b in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#12 0x00007ffff3806958 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0
#13 0x00007ffff51eaac3 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff51ea05a in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff51ea400 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff51ea4ac in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff4ab9cdd in g_application_run () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#18 0x00007ffff4f9de40 in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#19 0x00007ffff4f9d8ab in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#20 0x00007ffff59638fc in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
#21 0x00007ffff59653e8 in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
#22 0x00007ffff5959385 in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-35m-x86_64-linux-gnu.so
#23 0x00000000005bc727 in PyObject_Call ()
#24 0x000000000051f756 in PyEval_EvalFrameEx ()
#25 0x000000000051f254 in PyEval_EvalFrameEx ()
#26 0x0000000000523d29 in ?? ()
#27 0x00000000005249ef in PyEval_EvalCode ()
#28 0x0000000000601402 in ?? ()
#29 0x000000000060393a in PyRun_FileExFlags ()
#30 0x0000000000603b2c in PyRun_SimpleFileExFlags ()
#31 0x000000000063dc06 in Py_Main ()
#32 0x00000000004cfb91 in main ()

This hints that the only thing on the Python stack I would see would be the place where I call Gtk.Application.run(). In other words, my need for this feature is actually rather low.

[vstinner]

Did you try faulthandler.register(SIGTRAP)?
https://docs.python.org/dev/library/faulthandler.html#faulthandler.register

[mgedmin]

Welp! No, I tried to look for environment variables/python -X option flags/optional faulthandler.enable() arguments. Didn't page down the documentation page to see if there are other interesting functions. My bad!

(It works like a charm!)

[vstinner]

(It works like a charm!)

Cool. Good to know that faulthandler actually works :-)