[Bug malloc/19591] malloc does not work across a static dlopen boundary

[benoar at dolka dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=19591

Benjamin Cama <benoar at dolka dot fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benoar at dolka dot fr

--- Comment #1 from Benjamin Cama <benoar at dolka dot fr> ---
Hi Florian,

Tracing this bug, I arrived in malloc/malloc.c:_int_free (from a __libc_free()
call) where this check fails:

    /* Or whether the next chunk is beyond the boundaries of the arena.  */
    if (__builtin_expect (contiguous (av)
                          && (char *) nextchunk
                          >= ((char *) av->top + chunksize(av->top)), 0))

This happen because av->top gives the top of the *other* arena for some
pointer, i.e. dso_free() is called for an malloc()'ed pointer, or free() is
called for an dso_malloc()'ed pointer; depending on which one is mapped lower
than the other. The wrong arena is gotten by __libc_free thanks to
arena_for_chunk() macro, which gives here the default arena for this object
(DSO or static) (we are not using mmap'ed heaps) which is different for the
DSO's allocator or the static one. (not sure my explanations are clear enough
here)

So, the interoperability problem here is that different allocators assume
different default arena. I do not really know what would be a correct fix for
that, as the assumption that there is a default arena for some implementation
located at some specific place, even though they are the same implementation,
looks quite sensible to me.

One possibility would be to generalize the allocator the way it is done for
mmap'ed heaps, by aligning the main arena to HEAP_MAX_SIZE, so that
heap_for_ptr() works for main arena too. I am not knowledgeable enough to know
if this would be possible; at first sight, this looks difficult (aligning the
mapping + aligning the malloc_state struct), but I may be wrong.

Another possibility would be to add more “tag” to pointers so that we know
which arena they are from… but then I do not know how we could “chain” the
malloc/free/etc calls to the correct one.

Well, I see no good solution, so back to the original problem (I come from
#14413 originally) it seems you would like NSS to be able to realloc
user-provided pointers: this seem very complicated to me. If we just want to
malloc memory in getaddrinfo() from a DSO or whatever, the correct free() call
(logically from freeaddrinfo()) will always be called, as it come from the same
implementation, right? So, no need for this complicated “call the right
implementation” solution.

Any thought on that? Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.