On Jun 18, 2016, at 12:44 PM, Antony Polukhin wrote:

2016-06-18 17:49 GMT+03:00 Edward Diener :

...

...

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 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 std::basic_ostream& operator<<(std::basic_ostream& 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

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

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

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