[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Feb 2016 16:17:54 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: dynlink.c: bug in reclaim_gaps leading to segfault in
__libc_exit_fini
On Wed, Feb 17, 2016 at 09:03:27AM +0200, Timo Teras wrote:
> It is compliance issue. POSIX says about free:
Getting ahead of ourselves just a bit here, aren't we?
musl is a libc implementation. As such, it provides an implementation of
malloc(), realloc() and free(). Therefore, it also knows the internals
of its malloc() implementation and can therefore successfully simulate a
malloc() header, just enough so that free() can pick it up.
I don't think superposition applies to this point as well, because the
reference to free() will be resolved internally in the shared lib, and
in the static lib, this code doesn't matter, and even if it did, you
couldn't link you own malloc implementation with it, because it is libc
internal.
> The free() function shall cause the space pointed to by ptr to be
> deallocated; that is, made available for further allocation. If ptr is
> a null pointer, no action shall occur. Otherwise, if the argument does
> not match a pointer earlier returned by a function in POSIX.1-2008 that
> allocates memory as if by malloc(), or if the space has been
> deallocated by a call to free() or realloc(), the behavior is undefined.
"The behavior is undefined" means POSIX does not define the behavior,
and people merely using the interface should avoid this case. But musl
doesn't use this interface, it uses a guarenteed implementation.
>
> While overloading allocators are not supported, they'd break at this
> too. And it'll be highly annoying if someone decides to test a new
> memory allocator inside musl and does not know about this one exception.
>
Are you saying that people modifying musl better know what they are
doing? Because yeah, I kinda guessed that.
> Well - musl really should introduce __donatemem or similar for this
> purpose, and not overload the standard free() function. This would make
> the valgrind warning go away.
>
Aha. Write the code around the bug checker, yeah, that seems sane.
musl isn't overloading anything here, either. It is calling free(), and
that is the same free() users of malloc() should call. It does so with a
pointer to a specially crafted memory area.
> I'd rather not write a suppression for the above, since the internals
> are misusing/overloading a standard api call against posix.
>
You appear to not understand that musl isn't POSIX. musl is a specific
implementation of a few standards, POSIX being among them. Don't ix up
interface and implementation.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
