Boost logo

Boost :

Subject: Re: [boost] [Backtrace] Any interest in portable stack trace?
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-10-21 08:40:30

Hi All,

> One recommendation, decide early on limitations.
> I recommend to choose from the beginning:
> - whether it should work in asynchronous interrupts such as signal handlers,
> - whether it should work when the program is unstable, such as memory fault
>handlers, and
> - how good a performance to expect.

Very Good idea:

Limitations of use:

1. No it is not asynchronous interrupts safe
2. It would not likely work when the application is unstable or as serious
3. The trace collection is expected to be very fast (as walking on linked list)
4. The trace printing may be quite slow and costly, expected to be used quite


- Generally trace collection should be interrupt safe, but it is up to the
specific implementation
  of libc backtrace function on specific platform.
- It is possible to create degraded print tracing in case the process is
unstable such, it
  would be safe to use in signal handlers, but it is unlikely to provide full
  Only pointers data and not symbols.


- Under ELF platform - system should be compiled with -rdynamic
- Under Windows/MSVC - debug information should be provided.
- Function inlining and omitting frame pointers would significantly reduce
visible frames
  of calls.
- Static function would not be resolved under ELF platforms.

Bottom line:

- It can't be as powerful as Java's printStackTrace as C/C++ generally
  has fewer runtime information
- It can be very useful with top level catch blocks to see what happen.


P.S.: The implementation exists take a look on it and see if it useful enough
P.P.S.: I don't think the implementation should include much more then now.


Boost list run by bdawes at, gregod at, cpdaniel at, john at