Re: [boost] Gauging interest in patch submissions
GMan wrote:
My only concern with this is in a case like this, for example:
while (/* reading lines from file, parsing integers, otherwise ignoring*/) { try { myInts.push_back(boost::lexical_cast<int>(currentLineStr)); } catch (const boost::bad_lexical_cast&) // (has stack trace) {} }
Will the stack trace make such an operation noticeably slower? I know it's easy to retort with "don't use exceptions for flow control" but I believe my concern is valid, even if it's a bit contrived of a situation.
Perhaps we'd like to make it opt-in, like BOOST_THROW_EXCEPTION_TRACED or something.
I don't know what one considers "noticeably slower", but there will be overhead for sure. In our implementation, the creation of a tracable_exception object copies the current stack trace into itself. This may or may not be large depending on how many stack traces are defined. We've done our best to optimize our implementation but it's still an O(n) operation. There is one concern that I have with BOOST_THROW_EXCEPTION_TRACED. Will it affect the ABI? Suppose I compile against a Boost library that's installed on the system, and it was compiled without BOOST_THROW_EXCEPTION_TRACED. If I define BOOST_THROW_EXCEPTION_TRACED now will this change the exception hierarchy, and thus, the ABI? - 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)
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)
participants (1)
-
Hongli Lai