From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6169 Path: news.gmane.org!not-for-mail From: Scott Valentine Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lang.lua.general Subject: LUA + musl, garbage collection issue? Date: Sat, 20 Sep 2014 16:41:14 -1000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1411267302 8728 80.91.229.3 (21 Sep 2014 02:41:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Sep 2014 02:41:42 +0000 (UTC) To: lua-l@lists.lua.org, musl@lists.openwall.com Original-X-From: musl-return-6182-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 21 04:41:31 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 1XVX5e-00083D-E2 for gllmg-musl@plane.gmane.org; Sun, 21 Sep 2014 04:41:30 +0200 Original-Received: (qmail 16116 invoked by uid 550); 21 Sep 2014 02:41:28 -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 16108 invoked from network); 21 Sep 2014 02:41:28 -0000 X-TMN: [JAVAm3lYQbPML4xqG59lvTijoygb2TT2] X-Originating-Email: [scottvalen@hotmail.com] User-Agent: KMail/4.11.5 (Linux/3.14.17-100.fc19.x86_64; KDE/4.11.5; x86_64; ; ) X-OriginalArrivalTime: 21 Sep 2014 02:41:16.0038 (UTC) FILETIME=[83F53A60:01CFD545] Xref: news.gmane.org gmane.linux.lib.musl.general:6169 gmane.comp.lang.lua.general:113016 Archived-At: I have been testing OpenWRT builds using musl as the libc on arm and mips targets, and I have run into an issue which appears to be related to lua. Essentially, when using the luci web interface to upload a file to the device, I am running into a memory exhaustion problem. A 6 MB upload results in nearly 70MB of memory allocation. On smaller targets (i.e. 64MB RAM), it pretty much just locks up the system until the watchdog timer expires and reboots. On bigger targets with enough RAM, the process completes and the memory is freed, but I think this is because the lua process exits. On eglibc and uclibc builds I only see marginal memory increases during the upload, mostly do to the file getting written to tmpfs. I'm having trouble tracking down where the issue is, but it looks like lua exclusively uses realloc for managing memory. Is this correct? 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? Regards, -Scott V.