On 2017-04-04 16:04, Ian Lance Taylor wrote:
On Tue, Apr 4, 2017 at 6:50 AM, <bas...@starynkevitch.net> wrote:
On 2017-04-04 15:38, Ian Lance Taylor wrote:
How about we just add backtrace_destroy_state?
I don't know how to code that. In my
https://github.com/bstarynk/melt-monitor I observed that calling free
on
such
a struct backtrace_state pointer is breaking things.
Well, yes, it would have to call backtrace_free. But more than that
it would have to munmap the free list. So you're right that it's not
trivial.
I also find the code of backtrace_create_state a bit complex (maybe
for
historical reasons). Why does it call backtrace_alloc instead of just
calling malloc?
Because backtrace_create_state, like all the backtrace functions, can
be called from a signal handler. The backtrace code can never call
malloc. (It does call malloc on systems that do not support anonymous
mmap, because there is no other choice, which means that the backtrace
library does not really work entirely correctly on such systems.
Fortunately such systems are rare these days. See
BACKTRACE_USES_MALLOC.)
This is great news! I would be tempted to suggest another comment change
in backtrace.h saying that the functions are
(on most recent systems like Linux and those with anonymous mmap)
async-signal-safe (when the user callbacks are also that).
I was unaware of that delicious property of your libbacktrace. Ian, you
are impressing me even more than usual!
(I'm not a native English speaker or a POSIX guru, but to me the three
words async-signal-safe means something important;
I am borrowing them from
http://man7.org/linux/man-pages/man7/signal.7.html which might be my
favorite man page, with time(7)).
Cheers.
--
Basile Starynkevitch (France) http://starynkevitch/net/Basile/
