Re: [boost] Stacktrace library starts review today 14th Dec

Subject: Re: [boost] Stacktrace library starts review today 14th Dec
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-12-17 13:38:41

Am 17.12.2016 um 18:05 schrieb Antony Polukhin:
> 2016-12-17 17:10 GMT+03:00 Klemens Morgenstern <klemens.morgenstern_at_[hidden]>:
>>
>
>>>        - What is your evaluation of the implementation? Most of my
>>> personal concerns with this library are with the implementation and I
>>> would hugely appreciate feedback from others with substantial
>>> experience of using stacktracing "in anger" in non-trivial use case
>>> scenarios.
>>
>> Seems to be the overall right way to me. However there are a few problems:
>>
>> - backend_linux/add2line
>> Do I have a guarantee that this tool works right for every compiler on
>> linux? I would instinctively think not. If I'm right here, there should at
>> the very least be a macro which allows to change the program name.
>
> Most of the compilers use DWARF debugging because all the tools
> (debuggers,addr2line) understand it.
> The problem is that addr2line may not be installed. I'll clarify
> addr2line requirement in the docs and will try to find another way of
> getting debug info from address.

Thus (in addition to what Niall said) it should be configurable.

>
>> Also, I get why there's the stack-trace function at the top of the
>> stacktrace, and it would be the wrong approach to remove it manually. I
>> would however like a workaround, so that the stacktrace doesn't include
>> those calls.
>
> That top level frame may dissappear/reapper depending on the compiler
> version and even compiler flags. I was experimenting with skipping the
> first frame or forcing inlinement. I've found no good way to resolve
> that issue.
>
But that might be a problem. I would expect the stacktrace to be 
essentially the same on different compilers. I get why stripping is not 
a goot solution, but that seems problematic to me.
>
>> Something like that maybe: (CaptureStackBackTrace is obtained through a
>> fwd-declaration as in boost/winapi)
>>
>> #define BOOST_STACKTRACE(Name) \
>> boost::stacktrace::stacktrace Name(boost::stacktrace::detail::empty_tag());
>> \
>> BOOST_FILL_STACKTRACE(Name);
>>
>> #if defined(BOOST_STACKTRACE_WINDOWS)
>>
>> #define BOOST_FILL_STACKTRACE(Obj) \
>> { \
>>       boost::detail::winapi::ULONG_ hc = 0; \
>> ::CaptureStackBackTrace(0,static_cast<boost::detail::winapi::ULONG_>(
>> boost::stacktrace::stacktrace::size), \
>> Obj.native_handle(), &hc); \
>> }
>> #endif
>>
>> The downside would be, that this wouldn't work well with the link-solution
>> for noop. But maybe instead of using CaptureStackBackTrace directly, this
>> could be done through a function-ptr given by the linked library, so that it
>> can point to a noop.
>
> Calling a function pointer produces stack frame :(
What I meant was, having a pointer to CaptureStackBackTrace or an empty 
replacement. So it would be essentially the same as calling it directly. 
Thus you'd have a direct call to the sys-function. This could also be 
done with an alias as in compiler-extensions.

>
>> It would also be awesome if you could provide a better build description,
>> especially since this library may be used by other boost libraries in the
>> future.
>>
>> Something like that:
>>
>> lib foo : bar.cpp : <stacktrace>off ; //not link to anything
>> lib foo : bar.cpp : <stacktrace>noop ; //link against the empty backend
>> lib foo : bar.cpp : <stacktrace>windbg ; //windows
>> ...
>> lib foo : bar.cpp : <stacktrace>on ; //automatically select the default with
>> debug, none with release.
>>
>> I think if that is defined in stacktrace/build/Jamfile.v2 it would only be
>> available when building boost or having boost through use-project. That
>> would be very helpful.
>
> Just include the header <boost/stacktrace.hpp> and that's it. Nothing
> to be done in Jamfile.v2
>

Yeah, but what are those binaries for then?

>>>        - What is your evaluation of the documentation?
>>
>> I think that about right.
>>
>>>        - What is your evaluation of the potential usefulness of the
>>>          library?
>>>        - Did you try to use the library?  With what compiler?  Did you
>>>          have any problems?
>>
>> Yes, mingw 6 (didn't work) and msvc 19, where it worked.
>>
>> I got an error with msvc (RtlCaptureStackBackTrace not defined), because I
>> hadn't defined
>> _WIN32_WINNT correclty. It might be useful to add an error/warning for that.
>
> I'll fix that. There may be more such errors. Fortunately they all
> could be easily captured by the Boost testing matrix (if the library
> would be accepted into the Boost),
>
> Thank you for the review!
>

No Problem, it really fills a need.
Any Idea how to get it to work with mingw?