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
Am 18.06.2016 um 12:34 schrieb Antony Polukhin:
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?
I think that'd be great - even more so if you could integrate this with boost.test, so I could state an expectation of what my function calls. I.e. something like that: void f(int) {g(); h(); g();}; BOOST_CHECK_CALLS(f(42), g, h, g);
Klemens Morgenstern
Am 18.06.2016 um 12:34 schrieb Antony Polukhin:
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?
I think that'd be great - even more so if you could integrate this with boost.test, so I could state an expectation of what my function calls. I.e. something like that:
void f(int) {g(); h(); g();};
BOOST_CHECK_CALLS(f(42), g, h, g);
This is specific case for interaction based testing which is usually being done based on mocks. We would have very hard time to present something more or less generic without mocks. That being said, I'd be willing to work closely with anyone interested in bringing stacktrace to boost and integrate it into Boost.Test. It would be very useful to report stacks at the point of unexpected exceptions or fatal errors. Gennadiy
On 18 Jun 2016 at 19:42, Gennadiy Rozental wrote:
I think that'd be great - even more so if you could integrate this with boost.test, so I could state an expectation of what my function calls. I.e. something like that:
void f(int) {g(); h(); g();};
BOOST_CHECK_CALLS(f(42), g, h, g);
This is specific case for interaction based testing which is usually being done based on mocks. We would have very hard time to present something more or less generic without mocks.
That being said, I'd be willing to work closely with anyone interested in bringing stacktrace to boost and integrate it into Boost.Test. It would be very useful to report stacks at the point of unexpected exceptions or fatal errors.
I have some buns in the oven on that front: https://github.com/ned14/boost.kerneltest. It's the "other half" of automated testing, the part unit test frameworks or dependency injection don't usually cover: the Monte Carlo proof of correctness part. Longer run i.e. not in 2016 it'll use LLVM to trace every edge of execution and flow of data between the public facing library API and any external functions/syscalls it makes. It will then automatically permute the inputs and effects from external functions/syscalls to formally prove a piece of C++ behaves as specified. Trunk clang and trunk GCC is currently required for the requisite compiler and runtime support, hence I won't land this till 2017 at the earliest, though I have a cool proof of concept test here locally which even works right in the MSVC ABI (well done clang!). KernelTest is a natural fit for other tricks too, like running libfuzzer, the AFL, all the sanitisers, valgrind etc. It multithreads and multiprocesses naturally, so you can fire all your CPUs at the problem for the many hours it takes to cover every permutation. You can see an example of usage in AFIO v2's very first unit test: https://github.com/ned14/boost.afio/blob/master/test/tests/file_handle _create_close/runner.cpp with an example of a test kernel at https://github.com/ned14/boost.afio/blob/master/test/tests/file_handle _create_close/kernel_async_file_handle.cpp.hpp. As you'll see, the simplest use case is to supply a kernel, an array of outcomes, kernel parameters, preconditions and postconditions. KernelTest will iterate the kernel and check everything is correct, notifying your unit test framework of choice of any failures. The new fast ringbuffer logging system will trace paths of execution in the kernel, optionally logging stacktraces as it goes, to aid future permutation solvers. I have yet to implement disk persistence for the logging ringbuffer, it's a todo. This stuff only started working for the first time the Thursday just past as I've wrestling with ICEs in clang or VS2015. I've been working on it exclusively since the ACCU conference in April as it would be embarassing to present AFIO v2 at CppCon without any unit test suite as I had to do at ACCU. I would stress in the strongest possible terms that nobody should remotely consider using any of this stuff any time in 2016, wait till 2017 or probably 2018. But interested people may wish to star my github repos and watch out for conference videos, it's highly likely KernelTest + the monadic outcomes at its very core will make an appearance during the 2017 conference circuit. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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?
very useful! hope to see it in boost soon!
What functionality would you like to have in it?
file & line number ... at least for the top frame and possibly optional. this would require a macro, but might be useful for debugging ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXZbnxAAoJEAIkvWiom07Duu8P/3bUtKm1ByYba99HQ+wD/avn t1By+zLgmKQAxQFs0eeRM1LaeHydbfT7yc8G12MWY5x8ObuzvJ3vWraIag98tXT1 8u0RdpWPp2SWhbV2+X7a/CUgjOEYsD8N0fubchwZvfrKLhB9UqKdD39qNcWzi8H0 RTno9nh0zXrALoIcjz3T0VAWdDc40Rk0n3JifAsbOtvmZVhOq3DHbcQHSSb+CvNv ttOdFYbjaNeZCeZrG/u4j4qIM22tXdOmsomJiWIp6dKE0c+pp/XEZ63uHsJ6wNzv bBu8Aysl84fgWtt0gA9riqgLcoJwyZIfB2PkvnFXGh4DF4pxEgNz3Y+zzGGMAEPb 9XYAhk+UF6gGcNwkG1TDIyxn53mNvacWdqs8Bff8aVjoIEZzUFKKWPfZSCiVaEkx qq+5RnytRgpM/x2R/3Rd6IgD0/QzPGjs9de3FFxPoYVKMHc/HFieRprt6nkh+NjD NxE5rm2ZWUxE4wnY9th2rIkc+LWj69HZinKcPlonuGz5ufW8wwnR9J9kkPFc1y9j 2ZtQJJ96haHCtzZoCWp6v6190edfCS7M7kPbwMT/OAzHTOD9j/Wc8zZj43sN5els 05IYgUzSFVhIo9P/qkQBVUh3NtQaLPkrMmDB7WanirEtSlF6z/l/QfyNihT23ClZ ThMBQivf7ZxqRok3mDPq =c4/L -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
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? very useful! hope to see it in boost soon!
What functionality would you like to have in it? file & line number ... at least for the top frame and possibly optional. this would require a macro, but might be useful for debugging ... With gcc you can find that out with addr2line if you have the address of
Am 18.06.2016 um 23:15 schrieb Tim Blechmann: the function and or the source of the call (i.e. address of the statement). Not sure if that would need to be in the library then, though I don't know the other compilers.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJXZbnxAAoJEAIkvWiom07Duu8P/3bUtKm1ByYba99HQ+wD/avn t1By+zLgmKQAxQFs0eeRM1LaeHydbfT7yc8G12MWY5x8ObuzvJ3vWraIag98tXT1 8u0RdpWPp2SWhbV2+X7a/CUgjOEYsD8N0fubchwZvfrKLhB9UqKdD39qNcWzi8H0 RTno9nh0zXrALoIcjz3T0VAWdDc40Rk0n3JifAsbOtvmZVhOq3DHbcQHSSb+CvNv ttOdFYbjaNeZCeZrG/u4j4qIM22tXdOmsomJiWIp6dKE0c+pp/XEZ63uHsJ6wNzv bBu8Aysl84fgWtt0gA9riqgLcoJwyZIfB2PkvnFXGh4DF4pxEgNz3Y+zzGGMAEPb 9XYAhk+UF6gGcNwkG1TDIyxn53mNvacWdqs8Bff8aVjoIEZzUFKKWPfZSCiVaEkx qq+5RnytRgpM/x2R/3Rd6IgD0/QzPGjs9de3FFxPoYVKMHc/HFieRprt6nkh+NjD NxE5rm2ZWUxE4wnY9th2rIkc+LWj69HZinKcPlonuGz5ufW8wwnR9J9kkPFc1y9j 2ZtQJJ96haHCtzZoCWp6v6190edfCS7M7kPbwMT/OAzHTOD9j/Wc8zZj43sN5els 05IYgUzSFVhIo9P/qkQBVUh3NtQaLPkrMmDB7WanirEtSlF6z/l/QfyNihT23ClZ ThMBQivf7ZxqRok3mDPq =c4/L -----END PGP SIGNATURE-----
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 19/06/2016 09:18, Klemens Morgenstern wrote:
What functionality would you like to have in it? file & line number ... at least for the top frame and possibly optional. this would require a macro, but might be useful for debugging ... With gcc you can find that out with addr2line if you have the address of the function and or the source of the call (i.e. address of the statement). Not sure if that would need to be in the library then, though I don't know the other compilers.
You typically can't assume that you'll be able to get file and line from an address on a live system. Most installed software (via "install" on Linux or omitting the pdb file on Windows) consists of stripped binaries that specifically have the necessary information to do that omitted. (Since it can be quite large, and exposes things that proprietary folks prefer not to.) However it's still useful to be able to log a stack trace consisting only of addresses (and a build identifier) to a log file, that can then be reconstructed into line number info (via addr2line and similar tools) on another machine that has the non-stripped binaries (or PDB files) from the same build available. If the line number info is available at the time of the trace then it's nice to provide it when possible, to skip the extra step -- but this must be configurable, as often looking these up is much slower than generating the address-only trace, and some applications/threads won't want to pay for that.
On Mon, Jun 20, 2016 at 9:26 PM, Gavin Lambert
On 19/06/2016 09:18, Klemens Morgenstern wrote:
What functionality would you like to have in it?
file & line number ... at least for the top frame and possibly optional. this would require a macro, but might be useful for debugging ...
With gcc you can find that out with addr2line if you have the address of the function and or the source of the call (i.e. address of the statement). Not sure if that would need to be in the library then, though I don't know the other compilers.
You typically can't assume that you'll be able to get file and line from an address on a live system.
Most installed software (via "install" on Linux or omitting the pdb file on Windows) consists of stripped binaries that specifically have the necessary information to do that omitted. (Since it can be quite large, and exposes things that proprietary folks prefer not to.)
Additionally.. Even if you go through the steps to include that information in your custom binaries.. It is no uncommon for addr2line to not work even with the information. That might not be common in run-of-the-mill Linux systems. But it is common in custom built embedded Linux derivatives, like Android variants and game consoles. However it's still useful to be able to log a stack trace consisting only
of addresses (and a build identifier) to a log file, that can then be reconstructed into line number info (via addr2line and similar tools) on another machine that has the non-stripped binaries (or PDB files) from the same build available.
Which makes that approach the common way of dealing with stack trace information in the above context. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On June 18, 2016 6:34:38 AM EDT, Antony Polukhin
I've got some prototype for getting stack traces: https://github.com/apolukhin/stacktrace
Is there interest in it?
Yes
What functionality would you like to have in it?
IME, you need to filter a few layers of backtrace corresponding to your code. That is, don't reveal your function calls, just those of the caller. The option to look up file and line number is valuable. An option to control the call depth would be valuable. Rendering the backtrace using output iterators, or into a container, would give users maximum control over how to use the information. Rendering into a string would be a simpler form of that. (std::ostringstream allows for that, of course, but is a heavy tool to do so.) Demangling is helpful. How will you signal unsupported platforms? ___ Rob (Sent from my portable computation engine)
On 6/18/2016 06:34 AM, Antony Polukhin wrote:
Is there interest in it? Yes, some time ago I built a memory allocation tracker to find a resource leak in a very large codebase. I spent a lot of time figuring out how to get a stack trace programmatically which I could map to each allocation. Having something like this would have been great. What functionality would you like to have in it? For my use case, I needed to be able to print the stack trace. I also had to come up with a way to uniquely identify each stack trace. i.e. key comparable. Perhaps hashable would be useful too.
Thanks for coming up with this. I look forward to seeing it added to boost. Brandon
On 18 Jun 2016 at 13:34, Antony Polukhin wrote:
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.
For even simpler backtraces for the most common use case, I've implemented glibc's backtrace() function for Windows at https://github.com/ned14/boost-lite/blob/master/src/execinfo_win64.c. Identical API, almost identical output. BTW Antony if you have need for very fast backtracing of non-callee (i.e. other thread) stacks using the undocumented NT kernel functions which are two orders of magnitude faster than those in DbgHelp, ping me privately. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (9)
-
Antony Polukhin -
Brandon Kohn -
Gavin Lambert -
Gennadiy Rozental -
Klemens Morgenstern -
Niall Douglas -
Rene Rivera -
Rob Stewart -
Tim Blechmann