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

Am 17.12.2016 um 18:05 schrieb Antony Polukhin:

2016-12-17 17:10 GMT+03:00 Klemens Morgenstern :

...

...

...

- 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_castboost::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 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?