Re: libbacktrace PATCH: improve comment for backtrace_create_state

[basile at starynkevitch dot net]

On 2017-04-04 16:04, Ian Lance Taylor wrote:
> On Tue, Apr 4, 2017 at 6:50 AM,  <basile@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/