From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6170 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: LUA + musl, garbage collection issue? Date: Sun, 21 Sep 2014 00:38:31 -0400 Message-ID: <20140921043831.GF23797@brightrain.aerifal.cx> References: 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 1411274330 11935 80.91.229.3 (21 Sep 2014 04:38:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Sep 2014 04:38:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6183-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 21 06:38:46 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XVYv7-0007Lw-Li for gllmg-musl@plane.gmane.org; Sun, 21 Sep 2014 06:38:45 +0200 Original-Received: (qmail 30312 invoked by uid 550); 21 Sep 2014 04:38:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30304 invoked from network); 21 Sep 2014 04:38:44 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6170 Archived-At: On Sat, Sep 20, 2014 at 04:41:14PM -1000, Scott Valentine wrote: > I noticed that in order to free memory, it basically calls realloc > with 0 as the new size. Is this something musl doesn't handle well? > > I'm trying a rebuild with a check for n == 0 in musl's realloc > function to just free the pointer, and I'll report back. > > What is "the right thing to do" to fix this? Should lua not be using > realloc to free memory, or should musl handle the case better, if, > in fact this is the problem? This is a bug in lua; it's depending on a bug in glibc. POSIX attempts to allow the glibc behavior (see the text here: http://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html) but this allowance is invalid since it conflicts with the requirements of ISO C (and, as you can see in the above link, "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2008 defers to the ISO C standard.") The relevant ISO C requirement is: "The realloc function returns a pointer to the new object (which may have the same value as a pointer to the old object), or a null pointer if the new object could not be allocated." In particular, the only way realloc is permitted to return 0 is if the operation failed, in which case the old pointer is still valid (not freed). But even if the glibc behavior weren't conflicting with the C standard, it's still not valid for an application to assume it, and it's still undesirable behavior (because it's inconsistent with glibc's malloc, which returns a non-null, unique pointer for each malloc(0), and because it makes it impossible for applications to reliably determine whether the operation succeeded or failed). The whole situation is a big enough mess that I feel I can safely say that any application that ever passes 0 as the size argument to realloc has potentially-serious bugs. So if lua wants to free memory, it just needs to call free. Rich