This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/4] Add a signal-safe malloc replacement

On Wed, Dec 18, 2013 at 3:54 PM, Paul Pluzhnikov <> wrote:
> On Wed, Dec 11, 2013 at 2:03 AM, OndÅej BÃlka <> wrote:
>> On Tue, Dec 10, 2013 at 04:35:41PM -0800, Andrew Hunter wrote:
>>> This is patch 2/4 of the effort to make TLS access async-signal-safe.
>> ok with this.
> This patch causes a failure in nptl/tst-tls3 (on either x86_64 or i686).
> The problem is that nptl/allocatestack.c get_cached_stack does this:
>   /* Clear the DTV.  */
>   dtv_t *dtv = GET_DTV (TLS_TPADJ (result));
>   for (size_t cnt = 0; cnt < dtv[-1].counter; ++cnt)
>     if (! dtv[1 + cnt].pointer.is_static
>         && dtv[1 + cnt].pointer.val != TLS_DTV_UNALLOCATED)
>       free (dtv[1 + cnt].pointer.val);
>   memset (dtv, '\0', (dtv[-1].counter + 1) * sizeof (dtv_t));
>   /* Re-initialize the TLS.  */
>   _dl_allocate_tls_init (TLS_TPADJ (result));
>   return result;
> }
> But the DTV allocation came from __signal_safe_calloc, not a regular heap,
> so free()ing it causes:
> *** Error in `/build/nptl/tst-tls3': double free or corruption (out):
> 0x00007f0484a76010 ***
> We can't call __signal_safe_free() here either -- it's hidden in
> I think the right solution here is to introduce _dl_clear_dtv(), export
> it from, and stop (well, reduce) groveling in's insides from
> within libpthread.
> Andrew,
> Do you want me to try this, or would you rather fix it yourself?

Argh, this is an artifact of the sharding.  Introducing dl_clear_dtv
is patch 3--together with this they work fine.

I think the proper fix is to reorder the patches -- move Factor out
_dl_clear_dtv before this one (having it just call free, not
signal_safe_).  Then apply this patch and replace the free with
signal_safe_free here.)

(Rereading your email you may be proposing the same fix, or possibly
the equivalent idea of squashing 2/4 and 3/4 instead--I'm not quite
sure which. I have a small preference for keeping it as two patches
but won't fight if you submit it as one.)  If you have time to do
(either) fix today, go ahead; otherwise I will mail reordered patches
tomorrow morning.

Sound OK?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]