From: basile@starynkevitch.net
To: Ian Lance Taylor <iant@golang.org>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, iant@google.com
Subject: Re: libbacktrace PATCH: improve comment for backtrace_create_state
Date: Tue, 04 Apr 2017 14:14:00 -0000 [thread overview]
Message-ID: <1659a30dbbec9c220af69e7b00763c84@starynkevitch.net> (raw)
In-Reply-To: <CAKOQZ8z+USpriXAXHDRs37JipeAPTX7g3YFnfo1VqNgTqHxunQ@mail.gmail.com>
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/
prev parent reply other threads:[~2017-04-04 14:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 12:05 basile
2017-04-04 13:38 ` Ian Lance Taylor
2017-04-04 13:51 ` basile
2017-04-04 14:05 ` Ian Lance Taylor
2017-04-04 14:14 ` basile [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1659a30dbbec9c220af69e7b00763c84@starynkevitch.net \
--to=basile@starynkevitch.net \
--cc=gcc-patches@gcc.gnu.org \
--cc=iant@golang.org \
--cc=iant@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).