Created attachment 157627 [details] patch Currently tor fails to save stack traces because -lexecinfo is missing in command run by configure script, and HAVE_BACKTRACE isn't defined. The attached script adds this LDFLAGS since it is always better to have stack traces on.
When you compile tor with -lexecinfo, is backtrace test from the test suite working for you? I have patched configure.ac with AC_SEARCH_LIBS(backtrace, [execinfo]) and I am getting this: m> ./src/test/test-bt-cl assert Sep 24 23:42:08.584 [err] void tor_assertion_failed_(const char *, unsigned int, const char *, const char *): Bug: src/test/test_bt_cl.c:42: crash: Assertion 1 == 0 failed; aborting. (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: Assertion 1 == 0 failed in crash at src/test/test_bt_cl.c:42. Stack trace: (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x102c5e8 <log_backtrace+0x48> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x1039a07 <tor_assertion_failed_+0x97> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x102c2fd <crash+0x6d> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x102c32f <oh_what+0x1f> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x102c37f <a_tangled_web+0x1f> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x102c3cf <we_weave+0x1f> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x102c512 <main+0x112> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) Sep 24 23:42:08.589 [err] Bug: 0x102c1a1 <_start+0x1a1> at /home/saper/sw/tor/src/test/test-bt-cl (on Tor 0.2.7.3-rc 06cc9a9a2db2c32f) m> ./src/test/test-bt-cl crash ============================================================ T= 1443138133 Tor died: Caught signal 11 0x102c9dd <clean_up_backtrace_handler+0x8d> at /home/saper/sw/tor/src/test/test-bt-cl 0x8016a8997 <pthread_sigmask+0x497> at /lib/libthr.so.3 0x102c2b0 <crash+0x20> at /home/saper/sw/tor/src/test/test-bt-cl the "crash" trace seems to be truncated and the test fails. This is FreeBSD 10.1, base clang, clang3.7 (^^ stacktrace) and gcc5
See also https://trac.torproject.org/projects/tor/ticket/17151 upstream
I didn't try the test suite.
It seems to be that our libexecinfo in base is out of date (I'm using 10.1 but I think there were no commits there since then). Running against base libexecinfo: m> ./src/test/test-bt-cl crash ============================================================ T= 1443178736 Tor died: Caught signal 11 0x102c92d <clean_up_backtrace_handler+0x8d> at /home/saper/sw/tor/src/test/test-bt-cl 0x8016a8997 <pthread_sigmask+0x497> at /lib/libthr.so.3 0x102c205 <crash+0x25> at /home/saper/sw/tor/src/test/test-bt-cl m> ldd ./src/test/test-bt-cl ./src/test/test-bt-cl: libm.so.5 => /lib/libm.so.5 (0x801635000) libthr.so.3 => /lib/libthr.so.3 (0x80185d000) libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x801a81000) libc.so.7 => /lib/libc.so.7 (0x800821000) libelf.so.1 => /usr/lib/libelf.so.1 (0x801c84000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x801e99000) Running against libexecinfo 1.1_3 from ports: m> env LD_LIBRARY_PATH=/usr/local/lib ./src/test/test-bt-cl crash ============================================================ T= 1443178868 Tor died: Caught signal 11 0x8016a8997 <pthread_sigmask+1175> at /lib/libthr.so.3 0x8016a81a8 <pthread_getspecific+3544> at /lib/libthr.so.3 0x102c205 <crash+37> at /home/saper/sw/tor/src/test/test-bt-cl 0x102c27f <oh_what+31> at /home/saper/sw/tor/src/test/test-bt-cl 0x102c2cf <a_tangled_web+31> at /home/saper/sw/tor/src/test/test-bt-cl 0x102c31f <we_weave+31> at /home/saper/sw/tor/src/test/test-bt-cl 0x102c462 <main+274> at /home/saper/sw/tor/src/test/test-bt-cl 0x102c0f1 <_start+417> at /home/saper/sw/tor/src/test/test-bt-cl m> env LD_LIBRARY_PATH=/usr/local/lib ldd ./src/test/test-bt-cl ./src/test/test-bt-cl: libm.so.5 => /lib/libm.so.5 (0x801635000) libthr.so.3 => /lib/libthr.so.3 (0x80185d000) libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x801a81000) libc.so.7 => /lib/libc.so.7 (0x800821000) base libexecinfo has trouble unwinding stack of the crash() function, which allocates some empty space on stack. I can't get gdb and gdb791 to print a nice stacktrace when compiling with base r3.4 clang or 3.7, but after compiling tor with gcc48 one can see with gdb 7.9.1: m> gdb791 --args ./src/test/test-bt-cl crash GNU gdb (GDB) 7.9.1 [GDB v7.9.1 for FreeBSD] (...) Reading symbols from ./src/test/test-bt-cl...done. (gdb) run Starting program: /home/saper/sw/tor/src/test/test-bt-cl crash [New Thread 801c06400 (LWP 100201)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 801c06400 (LWP 100201)] crash (x=x@entry=2) at src/test/test_bt_cl.c:39 39 *(volatile int *)0 = 0; (gdb) bt #0 crash (x=x@entry=2) at src/test/test_bt_cl.c:39 #1 0x000000000040a030 in oh_what (x=x@entry=2) at src/test/test_bt_cl.c:58 #2 0x000000000040a080 in a_tangled_web (x=x@entry=2) at src/test/test_bt_cl.c:64 #3 0x000000000040a0d0 in we_weave (x=x@entry=2) at src/test/test_bt_cl.c:70 #4 0x0000000000409be3 in main (argc=<optimized out>, argv=<optimized out>) at src/test/test_bt_cl.c:119 (gdb) Base gdb wants DWARF 2 instead of 4 so it cannot read this.
So, the best would to force execinfo from ports!
> So, the best would to force execinfo from ports! Note that there are two parts involved here: the stack unwinder, and the symbol lookup functionality. libexecinfo in base provides the latter, while the libexecinfo port implements both. Note that "stack unwinding" implementation in the port is just: > void * > getreturnaddr(int level) > { > > switch(level) { > case 0: return __builtin_return_address(1); > case 1: return __builtin_return_address(2); > case 2: return __builtin_return_address(3); > case 3: return __builtin_return_address(4); > case 4: return __builtin_return_address(5); > case 5: return __builtin_return_address(6); > case 6: return __builtin_return_address(7); > case 7: return __builtin_return_address(8); > case 8: return __builtin_return_address(9); > case 9: return __builtin_return_address(10); > ... and requires all source to be compiled with a frame pointer in order to make this work.
Maintainer reset.
New maintainer, request feedback.
Ed, So, unwinder in libexecinfo from the port requires -no-omit-frame-pointer to work. What about the libexecinfo from the base? There is some unwind.c there too. Can libexecinfo even ever work without the -no-omit-frame-pointer option? Tor now always links with it. Yuri
Created attachment 176578 [details] (not for landing) option to use devel/libexecinfo (In reply to Yuri Victorovich from comment #9) -fno-omit-frame-pointer is default on FreeBSD for GCC and Clang regardless of -O<N> level. Fortunately, base system doesn't pass -fomit-frame-pointer by default and ports encourage either to remove or hide the flag behind OPTIMIZED_CFLAGS option. $ gcc6 -Q --help=optimizers -O3 | fgrep frame-pointer -fomit-frame-pointer [disabled]
The current version of Tor does link with libexecinfo.