Stacktrace

[aleks-f]

Is your feature request related to a problem? Please describe. When an exception occurs, it is often not easy to determine the location of it and the execution path leading to it.

Describe the solution you'd like There should be a way to determine where an exception occurred and what exactly lead to it, ie a stack backtrace with reasonable amount of information that is readily available from the exception. This information should be automatically embedded into the exception message in Poco::Exception ctors

Describe alternatives you've considered Anything and everything, from embedding the location of the exception into the message string to using NDC. Helpful, but laborious and not fully satisfactory.

Additional context After some research, the best solution available seems to be cpptrace.

Worklist:

• [x] POCO-ify cpptrace by thin-wrapping it as a standalone library, without dependency on any poco lib
• [x] Add Foundation dependency on trace lib in Poco::Exception
  • only if POCO_ENABLE_TRACE is defined (default off), otherwise nothing changes and there is no dependency
  • defining POCO_ENABLE_TRACE disables stripping
• [x] Linux
  • [x] Use libbacktrace, provided by GCC
  • [x] Use libbacktrace when compiling with clang (CMake) libbacktrace works well on Linux; on mac, it does not give any meaningful output (see discussion here)
• [ ] OSX
  • [x] a combination found to be working reasonably well (trace is produced, but no source line numbers) is:
  • CPPTRACE_GET_SYMBOLS_WITH_LIBDL
  • CPPTRACE_DEMANGLE_WITH_CXXABI
  • CPPTRACE_UNWIND_WITH_UNWIND
  • [ ] According to the author, DWARF should be the best choice for Mac tried both clang built-in and separate libdwarf (a bit troubling due to LGPL mixed-in code), with poor results (see discussion here)
• [ ] Windows
  • [ ] Visual studio project
  • [x] DBGHELP
• [x] CMake build

Tradeoffs:

• symbols are necessary, so only non-stripped builds give meaningful results
• release builds are obviously affected by optimization and may miss some information (such as eg. source code line numbers)

Output from trace example, debug build

[matejk]

What about cross library calls when some unexported functions are on the stack?

In one of our implementations to dump stack using dl it was not possible to get details of unexported function. For example:

1. /home/ubuntu/build/lib/libxtscommon.so.3.16 : Clavis::Common::Exception::Exception(Clavis::Common::Exception::ErrorCode, <char>, std::allocator<char> > const&)+0x180
2. /home/ubuntu/build/lib/libxtscommon.so.3.16 : Clavis::Common::Uuid::toString[abi:cxx11]() const+0x94
3. lib/common/test/xtscommon-test : ~unnamed-symbol~+0x29030
4. /home/ubuntu/build/lib/libgtest.so.1.15.2 : void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, char const*)+0xa0
5. /home/ubuntu/build/lib/libgtest.so.1.15.2 : testing::Test::Run()+0xf8
6. /home/ubuntu/build/lib/libgtest.so.1.15.2 : testing::TestInfo::Run()+0x160
7. /home/ubuntu/build/lib/libgtest.so.1.15.2 : testing::TestSuite::Run()+0x26c
8. /home/ubuntu/build/lib/libgtest.so.1.15.2 : testing::internal::UnitTestImpl::RunAllTests()+0x398
9. /home/ubuntu/build/lib/libgtest.so.1.15.2 : testing::UnitTest::Run()+0x128
10. lib/common/test/xtscommon-test : ~unnamed-symbol~+0x1d474
11. /lib/aarch64-linux-gnu/libc.so.6 : ~unnamed-symbol~+0x273fc
12. /lib/aarch64-linux-gnu/libc.so.6 : __libc_start_main+0x98
13. lib/common/test/xtscommon-test : ~unnamed-symbol~+0x24330

[aleks-f]

What about cross library calls when some unexported functions are on the stack?

Symbols must exist for trace to work and in this case they seem to be missing. Probably best to ask in cpptrace or backtrace forums.