security/tor-devel ports has a simple test case in C to check for correctness of the backtrace() reporting: https://gitweb.torproject.org/tor.git/tree/src/test/test_bt.sh https://gitweb.torproject.org/tor.git/tree/src/test/test_bt_cl.c https://gitweb.torproject.org/tor.git/tree/src/test/bt_test.py One needs https://trac.torproject.org/projects/tor/ticket/17151 applied to make sure tor's configure considers using external -lexecinfo When linking the test code against libexecinfo from base (using 10.1 amd64 r283908) a truncated result appears, because there is an unused reserved space on the stack: $ ./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 instead of > 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 when using libexecinfo from ports. Is it possible to update libexecinfo in base to fix this problem? See also * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200778 * https://trac.torproject.org/projects/tor/ticket/17151
I've tried base's clang 3.4, clang 3.7, gcc48 and gcc5. With clang it is even impossible to get function names in the gdb backtrace, even with gdb 7.9.1.
See the comment added in PR 200778 - this isn't a problem in base's libexecinfo but instead the unwind library in base.
(In reply to Ed Maste from comment #2) > a problem in ... the unwind library in base Is it so even after base r303394 ?