[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: malloca, freea are not thread-safe
From: |
Ondřej Bílka |
Subject: |
Re: malloca, freea are not thread-safe |
Date: |
Wed, 10 Jan 2018 22:08:29 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Wed, Jan 10, 2018 at 03:02:17PM +0100, Florian Weimer wrote:
> The mmalloca function used to implement malloca accesses a static
> global array without synchronization:
>
> #define HASH_TABLE_SIZE 257
> static void * mmalloca_results[HASH_TABLE_SIZE];
> …
> mmalloca (size_t n)
> {
> …
> /* Enter p into the hash table. */
> slot = (uintptr_t) p % HASH_TABLE_SIZE;
> h->next = mmalloca_results[slot];
> mmalloca_results[slot] = p;
>
> freea also causes valgrind warnings because it contains an
> out-of-bounds access. This is very undesirable because it will
> cause programmers to miss real bugs.
>
> This code has been copied into libunistring and results in a thread
> safety hazard there.
>
> Thanks,
> Florian
First let S = sa_alignment_max;
This could be done faster without hash table by making alloca result
aligned to 2 * S and malloc ones not aligned to 2 * S by adding some padding.
It would make check on free simpler. For allocation its fastest with
__builtin_alloca_with_align(x, 2 * sa_alignment_max)
Without that it more depends on how much gcc messes up alloca and if it
could optimize x & c1 & c2 to x & (c1 & c2) for constants c1 and c2.
With downward growing stack a=alloca(n) could be done as (%rsp - n) & (~(S-1))
then we align it with ret = (a & (~(2*S-1))) + 2 * S