Problem: no backtrace is printed on assert

[bluca]

Solution: add an optional dependency on libunwind, and if present
use it to print the backtrace when zmq_abort is called.

Fixes #1965

I made the output similar to GDB's backtrace. Example:

Resource deadlock avoided (src/mutex.hpp:123)
#0  0x7fd3f6b71030 in src/.libs/libzmq.so.5 (zmq::zmq_abort(char const*)+0x9)
#1  0x7fd3f6b772c9 in src/.libs/libzmq.so.5 (zmq::mailbox_safe_t::send(zmq::command_t const&)+0x212)
#2  0x7fd3f6b806e2 in src/.libs/libzmq.so.5 (zmq::object_t::send_own(zmq::own_t*, zmq::own_t*)+0x4d)
#3  0x7fd3f6b9600d in src/.libs/libzmq.so.5 (zmq::socket_base_t::add_endpoint(char const*, zmq::own_t*, zmq::pipe_t*)+0x29)
#4  0x7fd3f6b993d9 in src/.libs/libzmq.so.5 (zmq::socket_base_t::connect(char const*)+0xcd4)
#5  0x7fd3f6b9c194 in src/.libs/libzmq.so.5 (zmq::socket_base_t::bind(char const*)+0x9df)
#6  0x401a2f in tests/.libs/test_udp (main+0x50)
#7  0x7fd3f5b7aaa0 in /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5)
#8  0x40131d in tests/.libs/test_udp (_start+0x29)
#9  0x29 in ? (+0x29)
Aborted

Note that it's enabled by default if libunwind is found. I don't think this is a problem, since if the application linking to the library doesn't have debugging symbols, there is no useful output:

Resource deadlock avoided (src/mutex.hpp:123)
#0  0x7f21f2b03030 in src/.libs/libzmq.so.5 (zmq::zmq_abort(char const*)+0x9)
#1  0x7f21f2b092c9 in src/.libs/libzmq.so.5 (zmq::mailbox_safe_t::send(zmq::command_t const&)+0x212)
#2  0x7f21f2b126e2 in src/.libs/libzmq.so.5 (zmq::object_t::send_own(zmq::own_t*, zmq::own_t*)+0x4d)
#3  0x7f21f2b2800d in src/.libs/libzmq.so.5 (zmq::socket_base_t::add_endpoint(char const*, zmq::own_t*, zmq::pipe_t*)+0x29)
#4  0x7f21f2b2b3d9 in src/.libs/libzmq.so.5 (zmq::socket_base_t::connect(char const*)+0xcd4)
#5  0x7f21f2b2e194 in src/.libs/libzmq.so.5 (zmq::socket_base_t::bind(char const*)+0x9df)
#6  0x401a2f in tests/.libs/test_udp (?+0x9df)
#7  0x7f21f1b0d42f in /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5)
#8  0x40131d in tests/.libs/test_udp (?+0xf5)
#9  0xf5 in ? (+0xf5)
Aborted

[hitstergtd]

@bluca
Nice. Do we need to do the same for the CMake build infrastructure?

[bluca]

Yes, but requires a bit more work since there's nothing using pkg-config in cmake as far as I could see, so I wanted to get autotools in shape first

[bluca]

Also I'm not sure if libunwind can work on windows, so it's in the not-windows ifdef section of zmq_abort

[coveralls]

Coverage decreased (-0.1%) to 74.793% when pulling fd85cb7 on bluca:backtrace_assert into f98b5bb on zeromq:master.

[somdoron]

@bluca thanks!!!

[coveralls]

Coverage decreased (-0.02%) to 74.77% when pulling bb5037e on bluca:backtrace_assert into c1dc9d0 on zeromq:master.

[bluca]

No problem! Will send the CMake part as soon as I have time to look into it

[hitstergtd]

@bluca Didn't get a chance to reply, but thanks! 👍

[jemc]

Cool stuff.

I had looked at doing this a while ago, but got discouraged by libunwind not being ubiquitous/portable. Making it an optional dep and falling back to the old behaviour is the perfect solution!

[sunkin351]

(About libunwind functionality on windows) Visual Studio's extensive debugging environment allows stack tracing without third party libraries. There is no need to add any such dependencies for windows.

[hitstergtd]

@bluca -

• I think that print_backtrace should not be conditional on HAVE_UNWIND, but rather, it should be conditional on something like a WANT_CALLSTACK_TRACES option; this way we can no-op print_backtrace on systems where backtraces are generated using libunwind and its not available.
• For Windows, we can use CaptureStackBackTrace for the sake of printing backtraces, with the solution being: http://stackoverflow.com/a/1334586/6019885. Anything more than that, and the library user can always defer to MSVC IDE, as per @sunkin351. I will give this a spin next week.