Re: [boost] [Backtrace] Any interest in portable stack trace?

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 
issues
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 
rarely.

Notes:

- 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 
information.
  Only pointers data and not symbols.

Limitations:

- 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.

Artyom

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.