Re: [boost] Stacktrace review: concern, probable solution and review news

Subject: Re: [boost] Stacktrace review: concern, probable solution and review news
From: Peter Dimov (lists_at_[hidden])
Date: 2016-12-21 15:18:22

Antony Polukhin wrote:
> * Take a look at the llvm-symbolizer, atos and libdwraf; try hard to 
> produce a non-forking solution

This could help: https://github.com/facebookarchive/atosl

> * ? Deserialization/inspection of stacktrace on other machine

For that (actually, for the serialization/saving part) you need to give the 
user a list of modules and their load addresses. EnumProcessModules + 
GetModuleInformation + GetModuleFileName on Windows, so that the addresses 
are saved out as offsets within a module, not as absolute addresses.

> Things NOT to do ever:
> * Callbacks to do things on stacktraces - no way to satisfy all the needs 
> and make them optimal on all the platforms. Do some caching instead

I don't think that you can have an async-safe interface that does not 
replicate work needlessly per frame without using callbacks. Well, you 
could, if the user passes you large enough arrays, I suppose. char 
function[MAX_FRAMES][MAX_LENGTH], and same for file. A callback-based API 
needs much less memory. Or you could not provide an API for getting the 
functions/files/lines at all in one go and only offer output in text form.