Bug 200778 - security/tor: Added LDFLAGS+=-lexecinfo to allow stack traces to work
Summary: security/tor: Added LDFLAGS+=-lexecinfo to allow stack traces to work
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: patch
Depends on: 203333
Blocks:
  Show dependency treegraph
 
Reported: 2015-06-11 02:26 UTC by Yuri Victorovich
Modified: 2018-01-13 22:37 UTC (History)
4 users (show)

See Also:
vlad-fbsd: maintainer-feedback? (yuri)


Attachments
patch (472 bytes, patch)
2015-06-11 02:26 UTC, Yuri Victorovich
no flags Details | Diff
(not for landing) option to use devel/libexecinfo (1.33 KB, patch)
2016-11-03 05:16 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer 2015-06-11 02:26:37 UTC
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.
Comment 1 Marcin Cieślak 2015-09-24 23:49:35 UTC
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
Comment 2 Marcin Cieślak 2015-09-24 23:50:17 UTC
See also https://trac.torproject.org/projects/tor/ticket/17151 upstream
Comment 3 Yuri Victorovich freebsd_committer 2015-09-25 02:53:31 UTC
I didn't try the test suite.
Comment 4 Marcin Cieślak 2015-09-25 11:23:18 UTC
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.
Comment 5 Marcin Cieślak 2015-09-25 11:23:43 UTC
So, the best would to force execinfo from ports!
Comment 6 Ed Maste freebsd_committer 2015-09-25 14:02:03 UTC
> 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.
Comment 7 Rene Ladan freebsd_committer 2016-06-27 21:46:49 UTC
Maintainer reset.
Comment 8 VK freebsd_triage 2016-10-02 19:35:07 UTC
New maintainer, request feedback.
Comment 9 Yuri Victorovich freebsd_committer 2016-10-23 22:49:38 UTC
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
Comment 10 Jan Beich freebsd_committer 2016-11-03 05:16:03 UTC
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]
Comment 11 Yuri Victorovich freebsd_committer 2018-01-13 22:37:47 UTC
The current version of Tor does link with libexecinfo.