Backtraces for Vala
I watched the GUADEC talk about vala and the question regarding having backtraces on crashes. If this is wished, I would like to give it a try.
Why?
You get instantly a backtrace, what went wrong.
Why not coredumps?
Some systems don't do coredumps/coredumps are disabled and for for developers it is e.g. in issues easier to say: "Run the program in the commandline and give me the output", if reproducing is not possible because of reasons, instead of instrumenting the (maybe non-technical) user to install gdb, run it in there and so on.
Solution
Register signal handlers that print the backtrace. See here for example programs.
Currently linux-only experimentations.
Attempt 1: Using backtrace from execinfo.h
Example backtrace:
./backtrace(main+0x43)[0x4011e6]
/lib64/libc.so.6(+0x29550)[0x7ff83f566550]
/lib64/libc.so.6(__libc_start_main+0x89)[0x7ff83f566609]
./backtrace(_start+0x25)[0x401095]
Pro:
- No external library needed
- Shared libraries are contained in it.
Contra:
- Calling in signal handler is theoretically unsafe, but practically safe, if you call
backtrace
before. - Missing line numbers
- Function demangling not possible
Attempt 2: Bugbuddy
(Copied from https://gitlab.gnome.org/GNOME/gnome-builder/-/blob/main/src/bug-buddy.c)
Example backtrace:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fefcf43fefa in wait4 () from /lib64/libc.so.6
Id Target Id Frame
* 1 Thread 0x7fefcf2e6740 (LWP 500752) "bugbuddy" 0x00007fefcf43fefa in wait4 () from /lib64/libc.so.6
Thread 1 (Thread 0x7fefcf2e6740 (LWP 500752) "bugbuddy"):
#0 0x00007fefcf43fefa in wait4 () from /lib64/libc.so.6
#1 0x0000000000401211 in bug_buddy_sigsegv_handler (signum=11) at bugbuddy.c:22
#2 <signal handler called>
#3 0x000000000040137b in main (argc=1, argv=0x7ffc70ceb038) at bugbuddy.c:71
From To Syms Read Shared Object Library
0x00007fefcf583cd0 0x00007fefcf6121a2 Yes (*) /lib64/libglib-2.0.so.0
0x00007fefcf38b700 0x00007fefcf4fd36d Yes (*) /lib64/libc.so.6
0x00007fefcf2eb3b0 0x00007fefcf3437b2 Yes /lib64/libpcre.so.1
0x00007fefcf6cc0a0 0x00007fefcf6f2d35 Yes /lib64/ld-linux-x86-64.so.2
(*): Shared library is missing debugging information.
[Inferior 1 (process 500752) detached]
Pro:
- Really nice backtrace(s) and even more info
- Battle tested in GNOME-Builder
Contra:
- Does nothing if gdb is not installed (Pain point for Windows/MacOS)
- GPL licensed, thus maybe undesirable to some.
- Function demangling not possible
libbacktrace
Attempt 3: UsingExample backtrace:
Crash with signal 11
Backtrace:
<0x000000000040264e> __bt_vala_signal_handler /home/user/Programming/signal/signal_handler.c:74
<0x00007f582acf3a6f>
<0x00000000004026ca> main /home/user/Programming/signal/signal_handler.c:87
<0x00007f582acde54f>
<0x00007f582acde608>
<0x0000000000402214>
<0xffffffffffffffff>
Aborted (core dumped)
Pro:
- Most control: You could e.g. demangle function names
- Static linking possible
Contra:
- No pkgconfig file (Albeit a MR exists)
- Not packaged in many distributions Source
- Libbacktrace requires CLAs to contribute
I would like to implement this, I would tend to use libbacktrace, as especially function demangling is possible easily.
Would such change be accepted?