*Address space layout randomization* How does boost stacktrace cope with ASLR (address space layout randomization)? This is where the load address of a module is randomized by the operating system loader to at an unpredictable address to help protect from viruses using techniques like buffer overrun attacks. The use case that I am concerned about is calling boost::stacktrace::safe_dump_to and later resolving the function names with boost::stacktrace::stacktrace::from_dump. Without the module load addresses (and the module paths) I do not see how the frame symbols can be resolved. I think that it is possible to address this by a future enhancement like having a process modules class possibly with a similar interface to boost stacktrace, and then to boost::stacktrace::stacktrace::from_dump might be extended take an additional argument of a 'process modules' class which has similarly been reconstructed. Having said this since I understand your expectation is possibly not to use in production (as build flags need to be set) then this may not be so serious, for use in production I would consider it a serious problem. I would like to be able to use this in production with both ASLR enabled and with code that may have optimizations on that make the stack harder to trace (including third party code for which I have no control of build settings). *Aggressiveness in walking stack:* It is inevitable that developers will want to use this in production code likely a release build with the optimizer on. Thus I was hoping for an option to use more aggressive algorithms (which could not be used within signal handlers). Using only the least aggressive method will significantly limit the usefulness -- but probably better to have a 1.0 version that requires compiler options than nothing maybe a 2.0 version will be able to support more aggressive algorithms for walking the stack. *Use on non-current threads:* To collect a stack in a different thread I know is possible and portably because I've seen it done on most platforms (this is what a debugger does when it dumps the stack of a target process). This is why the ReadMemory argument in Microsoft's StackWalk64 API is provided. All that is required is that we know that the thread being walked is paused. The idea being that if a deadlock is detected stacks for multiple threads can be logged but without of course requiring the deadlocked threads to do the walking. Potentially if stack tracing of other processes where supported it could be used to write watch dog processes, and even generate a stack trace for a stack overflow error (which is notoriously difficult to code for). *Out of the box caching:* Without adding extra classes the best I have is to add global map of address to string/symbol info (possibly with pruning of least used elements) for use by frame::name etc. The concern I have is thus: Let's say to_string for a single frame takes ~ 0.1 seconds. Let's say our stack trace is 10 frames deep. The to_string for the entire stack trace takes ~ 1 second. If a developer adds logging for some apparently rare exception in the hope of diagnosing a problem, but in production under some circumstance that exception occurs maybe once in 2 seconds, then the code will spend half it's wall time just logging stack traces. Basically it is too easy to accidentally grind some code to a halt by adding a diagnostic - which I think it just too dangerous. So my only advice / idea is to provide a global thread safe cache for symbolic information that is configurable either by functions in the namespace boost::stacktrace (preferred) or by build options. *Control over what frame::to_string / frame::name do * What I was thinking was whether there should be some user control over how the name for the frame is reported e.g. bar(int), void bar(int), void namespace::bar(int), bar(), __stdcall void bar(int), ?bar@@YAH@Z This is not something that I consider particularly important, it might be food for thought for you. I know that this is quite a bit of comment and that the official review period is over (I was getting married plus honey moon while the review was on). I do think this is an great addition to have in boost. - Mark -- View this message in context: http://boost.2283326.n4.nabble.com/stacktrace-Two-days-remaining-before-revi... Sent from the Boost - Dev mailing list archive at Nabble.com.