This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>, Konstantin Serebryany <kcc at google dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Andrew Hunter <ahh at google dot com>, address-sanitizer at googlegroups dot com
- Date: Mon, 20 Jan 2014 19:27:58 -0500
- Subject: Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- Authentication-results: sourceware.org; auth=none
- References: <52D0BCED dot 3000109 at redhat dot com>
Konstantin,
I've forwarded your response to libc-alpha which I assume rejected
your multi-part plain/html email.
I've also corrected the small mistake that the next release is 2.19
not 2.20. Sorry.
+address-sanitizer@googlegroups.com
Hi Carlos,
Thanks for the heads up!
I don't expect any impact on ASan from this change.
We'd still test ASan with the new glibc to make sure.
--kcc
On Sat, Jan 11, 2014 at 7:39 AM, Carlos O'Donell <carlos@redhat.com> wrote:
Hello Konstantin!,
You're getting this email because you're the only ASan expert I know,
and I was at your talk at LFCS2013 ;-)
We have a problem and we'd like your input if you have time.
The GNU C Library version 2.20 (coming out at the end of the month)
plans to stop using malloc for TLS allocations. The reason for this
is that malloc is async-signal unsafe, and TLS accessed in signal
handlers may need to allocate storage at the time of access. This
is particularly true of signal handlers provided by dlopened shared
libraries. There is no way to interpose yourself here because the
non-malloc signal-safe allocator being used is internal to glibc.
What kind of impact do you see this having on ASan?
Do you see any way we can mitigate this impact?
Cheers,
Carlos.