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@phusion.nl Chamber of commerce no: 08173483 (The Netherlands)