Boost logo

Boost :

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:

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

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