Re: [boost] Gauging interest in patch submissions

Subject: Re: [boost] Gauging interest in patch submissions
From: Hongli Lai (hongli_at_[hidden])
Date: 2011-09-29 02:50:08

Emil Dotchevski:
> Can't this be done non-intrusively, in a platform-specific matter? I
> know it's difficult and tricky, but stack traces can often be helpful
> in tracking errors. Having the user register trace points explicitly
> makes the system not as helpful. :(

This was one of the first things we considered. I don't know about
Windows, but on glibc and OS X one can obtain the stack trace with the
backtrace_symbols() function (GNU extension). Other platforms, like
FreeBSD, NetBSD and Solaris, don't seem to provide any API for
obtaining the stack trace, so one will have to resort to manually
inspecting the system stack whose format is probably compiler/ABI
specific.

Phusion Passenger's primary target platforms are Linux and OS X
(that's where most of our users are) so I suppose it's acceptable to
only support stack tracing for them, were it not for the following
problems:
- backtrace_symbols() is slow. Very slow. It was written for SIGSEGV
crash reports and the like. In case of Phusion Passenger, we often
want to catch the exception (which may be the result of a socket
error, and thus happens fairly often), report it and continue. The
enormous overhead imposed by backtrace_symbols() was deemed
unacceptable. In contrast, our manual stack tracing method is very
fast, I think as fast as it can be.
- backtrace_symbols() does not demangle C++ symbol names.
- backtrace_symbols() does not work properly across library
boundaries. It will display the entire stack trace, but for a lot of
items only their addresses. This is useless, we need human-readable
symbol names.

In the end we chose not to use it.

- Hongli
-- 
Phusion | Ruby & Rails deployment, scaling and tuning solutions
Web: http://www.phusion.nl/
E-mail: info_at_[hidden]
Chamber of commerce no: 08173483 (The Netherlands)