[boost] Checking interest in stacktrace library
Hi, I've got some prototype for getting stack traces: https://github.com/apolukhin/stacktrace It's design is based on the idea that class for stacktrace must be fully noexcept, without dynamic allocations in constructors and as simple as possible. Is there interest in it? What functionality would you like to have in it? -- Best regards, Antony Polukhin
On 6/18/2016 6:34 AM, Antony Polukhin wrote:
Hi,
I've got some prototype for getting stack traces: https://github.com/apolukhin/stacktrace It's design is based on the idea that class for stacktrace must be fully noexcept, without dynamic allocations in constructors and as simple as possible.
Is there interest in it? What functionality would you like to have in it?
Documentation is always helpful.
2016-06-18 17:49 GMT+03:00 Edward Diener <eldiener@tropicsoft.com>:
On 6/18/2016 6:34 AM, Antony Polukhin wrote:
Is there interest in it? What functionality would you like to have in it?
Documentation is always helpful.
Yeep, that's currently missing :( If in short: namespace boost { namespace stacktrace { class stacktrace { public: BOOST_STATIC_CONSTEXPR std::size_t max_symbol_width = 256; typedef boost::array<char, max_symbol_width> frame_t; stacktrace() BOOST_NOEXCEPT; stacktrace(const stacktrace& bt) BOOST_NOEXCEPT; stacktrace& operator=(const stacktrace& bt) BOOST_NOEXCEPT; ~stacktrace() BOOST_NOEXCEPT; std::size_t size() const BOOST_NOEXCEPT; frame_t operator[](std::size_t frame) const BOOST_NOEXCEPT; }; template <class CharT, class TraitsT> std::basic_ostream<CharT, TraitsT>& operator<<(std::basic_ostream<CharT, TraitsT>& os, const stacktrace& bt); }} So you can construct stacktraces, copy them and output them to streams: std::cerr << stacktrace(); -- Best regards, Antony Polukhin
On Jun 18, 2016, at 12:44 PM, Antony Polukhin <antoshkka@gmail.com> wrote:
2016-06-18 17:49 GMT+03:00 Edward Diener <eldiener@tropicsoft.com>:
On 6/18/2016 6:34 AM, Antony Polukhin wrote: Is there interest in it? What functionality would you like to have in it?
Documentation is always helpful.
Yeep, that's currently missing :(
If in short: namespace boost { namespace stacktrace { class stacktrace { public: BOOST_STATIC_CONSTEXPR std::size_t max_symbol_width = 256; typedef boost::array<char, max_symbol_width> frame_t;
stacktrace() BOOST_NOEXCEPT; stacktrace(const stacktrace& bt) BOOST_NOEXCEPT; stacktrace& operator=(const stacktrace& bt) BOOST_NOEXCEPT; ~stacktrace() BOOST_NOEXCEPT;
std::size_t size() const BOOST_NOEXCEPT; frame_t operator[](std::size_t frame) const BOOST_NOEXCEPT; };
template <class CharT, class TraitsT> std::basic_ostream<CharT, TraitsT>& operator<<(std::basic_ostream<CharT, TraitsT>& os, const stacktrace& bt); }}
So you can construct stacktraces, copy them and output them to streams:
std::cerr << stacktrace();
I think a library like this could be very useful for practical cross-platform development. Are there any means for either inspecting the contents of the trace (e.g. iterating over the frames and extracting things like the function name, offset, source file/line if available, etc.)? Alternatively, is there any way to control the formatting of the trace when it is inserted into a stream? If not, is the format platform-specific or in some common layout? Jason
On Sat, Jun 18, 2016 at 12:51 PM, Jason Roehm <jasonr@3db-labs.com> wrote:
On Jun 18, 2016, at 12:44 PM, Antony Polukhin <antoshkka@gmail.com> wrote:
2016-06-18 17:49 GMT+03:00 Edward Diener <eldiener@tropicsoft.com>:
On 6/18/2016 6:34 AM, Antony Polukhin wrote:
Is there interest in it? What functionality would you like to have in it?
Documentation is always helpful.
Yeep, that's currently missing :(
If in short:
namespace boost { namespace stacktrace {
class stacktrace { public: BOOST_STATIC_CONSTEXPR std::size_t max_symbol_width = 256; typedef boost::array<char, max_symbol_width> frame_t;
stacktrace() BOOST_NOEXCEPT; stacktrace(const stacktrace& bt) BOOST_NOEXCEPT; stacktrace& operator=(const stacktrace& bt) BOOST_NOEXCEPT; ~stacktrace() BOOST_NOEXCEPT;
std::size_t size() const BOOST_NOEXCEPT; frame_t operator[](std::size_t frame) const BOOST_NOEXCEPT; };
template <class CharT, class TraitsT> std::basic_ostream<CharT, TraitsT>& operator<<(std::basic_ostream<CharT, TraitsT>& os, const stacktrace& bt);
}}
So you can construct stacktraces, copy them and output them to streams:
std::cerr << stacktrace();
I think a library like this could be very useful for practical cross-platform development.
Years back I implemented an abstraction for this which I contributed to ACE (http://www.dre.vanderbilt.edu/%7Eschmidt/ACE.html) https://github.com/DOCGroup/ACE_TAO/blob/master/ACE/ace/Stack_Trace.h https://github.com/DOCGroup/ACE_TAO/blob/master/ACE/ace/Stack_Trace.cpp You might be able to use the implementations there as a starting point. -- Chris Cleeland
On 18.06.2016 12:34, Antony Polukhin wrote:
Hi,
I've got some prototype for getting stack traces: https://github.com/apolukhin/stacktrace It's design is based on the idea that class for stacktrace must be fully noexcept, without dynamic allocations in constructors and as simple as possible.
Is there interest in it? What functionality would you like to have in it?
Years ago I was briefly experimenting with capturing the stack backtrace in the exception objet before throwing it, but couldn't make it work reliably on some platforms. Windows code in particular was very sensitive to compiler options. So yes, I could find a portable library like that useful. Cheers, Leon
On 19/06/2016 11:32, Leon Mlakar wrote:
Years ago I was briefly experimenting with capturing the stack backtrace in the exception objet before throwing it, but couldn't make it work reliably on some platforms. Windows code in particular was very sensitive to compiler options.
If you're on Windows (and using an MS compiler), exceptions capture stack traces anyway. Extracting them is a bit more of a black art however, and as you said there are a couple of compiler options in particular that will affect the traces.
If you're on Windows you have dbghelp Win32 functions which are no black art and quite straight forward to use. -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: Tuesday, June 21, 2016 6:19 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] Checking interest in stacktrace library On 19/06/2016 11:32, Leon Mlakar wrote:
Years ago I was briefly experimenting with capturing the stack backtrace in the exception objet before throwing it, but couldn't make it work reliably on some platforms. Windows code in particular was very sensitive to compiler options.
If you're on Windows (and using an MS compiler), exceptions capture stack traces anyway. Extracting them is a bit more of a black art however, and as you said there are a couple of compiler options in particular that will affect the traces. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 21/06/2016 15:51, Ernest Zaslavsky wrote:
If you're on Windows you have dbghelp Win32 functions which are no black art and quite straight forward to use.
Those will generate a stack trace from the current location of a given thread (usually the current thread). That's fine, but not what I was referring to. I meant extracting the stack trace of the original throw point from some place that catches an exception (possibly a top-level uncaught exception handler). That's the black art. It requires either cooperation of the throw point or delving into compiler-specific internals.
Not sure I got you right. Do you mean catching exception somewhere top level and then showing stack of the original throw point? Isnt it stored (sorry, it was a long time ago) in EXCEPTION_POINTERS' member ContextRecord? AFAIR, if you use __try and __except and pass expression to __except with GetExceptionInformation() you are good to extract the original location of the exception (apparently unhandled) be it C++ or structured exception. Again, AFAIR, the only compiler option you have to set is /SEH -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: Tuesday, June 21, 2016 11:43 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] Checking interest in stacktrace library On 21/06/2016 15:51, Ernest Zaslavsky wrote:
If you're on Windows you have dbghelp Win32 functions which are no black art and quite straight forward to use.
Those will generate a stack trace from the current location of a given thread (usually the current thread). That's fine, but not what I was referring to. I meant extracting the stack trace of the original throw point from some place that catches an exception (possibly a top-level uncaught exception handler). That's the black art. It requires either cooperation of the throw point or delving into compiler-specific internals. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 21/06/2016 21:07, Ernest Zaslavsky wrote:
Not sure I got you right. Do you mean catching exception somewhere top level and then showing stack of the original throw point? Isnt it stored (sorry, it was a long time ago) in EXCEPTION_POINTERS' member ContextRecord? AFAIR, if you use __try and __except and pass expression to __except with GetExceptionInformation() you are good to extract the original location of the exception (apparently unhandled) be it C++ or structured exception.
Yes, that's true. I had another look and the esoteric part that I was remembering was extracting the exception message from within the same SEH handler. Getting the stack trace is relatively trivial.
Again, AFAIR, the only compiler option you have to set is /SEH
I assume you mean /EHa. That's not actually required IIRC (and using it sometimes sparks religious debates) but it does let you catch and unwind more exception types than /EHs does, which is sometimes handy, albeit with a performance cost. Also /Oy- helps with getting stack traces in general (GCC equivalent is -fno-omit-frame-pointer).
Yes, sure, /EHa And you are right, it not a must to enable it, but if you want to handle structured exceptions on Windows instead of terminating the process you have to enable it, AFAIR. -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Gavin Lambert Sent: Wednesday, June 22, 2016 10:06 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [boost] Checking interest in stacktrace library On 21/06/2016 21:07, Ernest Zaslavsky wrote:
Not sure I got you right. Do you mean catching exception somewhere top level and then showing stack of the original throw point? Isnt it stored (sorry, it was a long time ago) in EXCEPTION_POINTERS' member ContextRecord? AFAIR, if you use __try and __except and pass expression to __except with GetExceptionInformation() you are good to extract the original location of the exception (apparently unhandled) be it C++ or structured exception.
Yes, that's true. I had another look and the esoteric part that I was remembering was extracting the exception message from within the same SEH handler. Getting the stack trace is relatively trivial.
Again, AFAIR, the only compiler option you have to set is /SEH
I assume you mean /EHa. That's not actually required IIRC (and using it sometimes sparks religious debates) but it does let you catch and unwind more exception types than /EHs does, which is sometimes handy, albeit with a performance cost. Also /Oy- helps with getting stack traces in general (GCC equivalent is -fno-omit-frame-pointer). _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 21.06.2016 05:19, Gavin Lambert wrote:
On 19/06/2016 11:32, Leon Mlakar wrote:
Years ago I was briefly experimenting with capturing the stack backtrace in the exception objet before throwing it, but couldn't make it work reliably on some platforms. Windows code in particular was very sensitive to compiler options.
If you're on Windows (and using an MS compiler), exceptions capture stack traces anyway. Extracting them is a bit more of a black art however, and as you said there are a couple of compiler options in particular that will affect the traces.
Well, it really was many years ago ... when I was young, inexperienced and didn't particularly like wins environment. At least one of these things ain't true any more. Cheers, Leon
participants (7)
-
Antony Polukhin -
Chris Cleeland -
Edward Diener -
Ernest Zaslavsky -
Gavin Lambert -
Jason Roehm -
Leon Mlakar