Skip to content

Stacktrace #4692

@aleks-f

Description

@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:

  • POCO-ify cpptrace by thin-wrapping it as a standalone library, without dependency on any poco lib
  • 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
  • Linux
    • Use libbacktrace, provided by GCC
    • 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
    • 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
    • DBGHELP
  • 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

image

Metadata

Metadata

Assignees

Type

No type

Projects

Status

Done

Relationships

None yet

Development

No branches or pull requests

Issue actions