From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9347 Path: news.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: dynlink.c: bug in reclaim_gaps leading to segfault in __libc_exit_fini Date: Wed, 17 Feb 2016 16:17:54 +0100 Message-ID: <20160217151754.GA21193@debian> References: <20160216215550.GC9915@port70.net> <20160217090327.4c6b5790@vostro.util.wtbts.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1455722290 26579 80.91.229.3 (17 Feb 2016 15:18:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 15:18:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9360-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 17 16:18:09 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aW3rk-0001zI-K7 for gllmg-musl@m.gmane.org; Wed, 17 Feb 2016 16:18:08 +0100 Original-Received: (qmail 26236 invoked by uid 550); 17 Feb 2016 15:18:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26218 invoked from network); 17 Feb 2016 15:18:05 -0000 Content-Disposition: inline In-Reply-To: <20160217090327.4c6b5790@vostro.util.wtbts.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:IwAZ3SY/eLa4OoRRBJPXO/V3IKANpLKh+NpSPV4WNy3Or4c97lZ t5aZa6xEQQ0foYT7Bw4pEgQ5I9jslRyI0dEYYKQCOcGNyOFM/diLUh5rCT6rSb89CBmz6gO KaCQzG9oY+XHl/gTfcAHOC3hWCrCzkkzmdSUEi8PBsdHBvzdJ8iRTzUvwYw2k2lWUXPL/Vy qSHZndpiDexwTk7zGhhew== X-UI-Out-Filterresults: notjunk:1;V01:K0:tQwYtFdRT/o=:20+W/DBbe/HLwBkDOgs7Qu H12eCfhlPlOqHLkNcu6dDNA92VsL/JXFDz5PXdNS0YDpJvYSMA4aO9iJjbK0q43XzDEz6jnzi 9Mn3PfIp6gwrM8NalNXqsGRXWiWUlK075C4tcSatvFawO0n/JRx+k6vHgYQbp7uE6aNM4h1mj Xi6bGqHxyDBfKT/DYUNrQ8OTZKdnwtqHrTrrwgKaH5ZtW60LzLLrSqkbrFFUqaOJ8HtBwDpp0 K7ESPhfpMd8CYolYYCZ0MzY+Ht8YjUColtzlsnpPJJ2XWLOnGJJKGzrQ6PsaGBUrbG4SpHnep +ddmgKifwkhoFtw9TqFukY41Cc5yygk1zfIVMDeLdp5C9QnvLGzFgnlxul8vyMnHAGyP6Cn1w XPyEI5QcIW+foWhw3bN4Jt3vtMiZirrGtFmy5rQAN7EjEzd5cwWXexFLzTQBNVkN6DBLOlkFD I/me38Vn8HSPUk0yY87OwA78bKfxJdez7Jk7MGA4gya7ywYwSuEK3ZqfglfYuOnWEaZ48YGxj jm6c5N+K8OY7MIdfDCYBSOrQnhiY8oMZWGa1OnS+dM5qxKQtaOoXJKnJhonUa+27cAPrny8en ERZOQYjuO0XL597WfERecMAGjC5xxepRaP+9Qh4zVaC7zy0FHd79Dow/6gw6h3xSjKqt5p+Z9 2wl7nfvpWIXLotCGdfaTwsbvnjRhEm/6I9bpCs9FKPGlzXgr1t196O/N4PP5kI363Bs6Kicm4 qrAwlAO/S36ZdQ5zagirqP9Lh7gv+ZbpQILca/NxQu3U9TzDETjCWS4YKZEgmnPfr4YId+Ly Xref: news.gmane.org gmane.linux.lib.musl.general:9347 Archived-At: 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