Subject: Re: [boost] [stacktrace] review (changing vote to NO)
From: Artyom Beilis (artyom.beilis_at_[hidden])
Date: 2016-12-25 08:22:04
> > 1. use of -rdynamic/-export-dynamic should be noted in "bold face" regarding
> > the use of the library.
> Those flags are not required because addr2line can extract information
> from debug sections of the binary.
Yes.. this is exactly the issue - I don't think that addr2line should
be used by default.
Getting the stack trace using dladdr works very well - so no need to
use add2line unless absolutely required.
I also want to hear regarding inefficiency of add2line use - creating
the process for each stack frame you wanted to trace. It is very
inefficient so I suggest not to use one.
Finally reviewing your code once again I realized following:
1. Instead of using adde2line to get the object name you can just call
add2line with /proc/12345/exe (works with dynamically loaded shared
objects as well - i tested it)
2. Use of addr2line for every each frame must be fixed
But what is most important that I understood that you don't even use
dladdr to get function names even if you can - which is very bad
Additionally I realized that with_trace and traced aren't parts of the
library! These should be built in there by default.
After using the library and running couple of tests on Linux with GCC..
I have to revoke my "Conditional YES" vote and change it to "NO":
And the reason is following:
1. Linux/*nix backend is poor - instead of using dladdr to get
function names easily as I do in the backend I written and use on
CppCMS  you call external exe in very inefficient way.
2. I realized that the library does not provide the basic
functionality like collecting strack trace on throw (what I thought
was built in but I was mistaken)
3. No answer for non MSVC compilers built in.
But the most important reason that the library does not feel mature
enough in terms of both backends and frontends.
I strongly strongly strongly recommend to continue the work on the
library as it provides important functionality.
The frontend should be adjusted a little to couple with common cases.
The backend must be modified to not to fork/exec by default and
optimize one significantly.
I clearly understand you to want to use addr2line as it gives more
power but it can't be used by default. I searched for a long time for
a lightweight solution for converting addresses to the function names
for CppCMS including trying to use debug information but couldn't find
anything suitable besides dlfunc. However addr2line is by no means can
be accepted as "default" solution.
I also recommend to take a look on cppcms's backtrace library it is
very simple and provides critical information in production
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk