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.