From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6192 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: LUA + musl, garbage collection issue? Date: Wed, 24 Sep 2014 07:50:01 +0200 Message-ID: <20140924055001.GA21835@port70.net> References: <20140921043831.GF23797@brightrain.aerifal.cx> 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 1411537822 13171 80.91.229.3 (24 Sep 2014 05:50:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Sep 2014 05:50:22 +0000 (UTC) Cc: Justin Cormack To: musl@lists.openwall.com Original-X-From: musl-return-6205-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 24 07:50:17 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 1XWfSw-0004Sv-OJ for gllmg-musl@plane.gmane.org; Wed, 24 Sep 2014 07:50:14 +0200 Original-Received: (qmail 28284 invoked by uid 550); 24 Sep 2014 05:50:13 -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 28276 invoked from network); 24 Sep 2014 05:50:13 -0000 Mail-Followup-To: musl@lists.openwall.com, Justin Cormack Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6192 Archived-At: * Scott Valentine [2014-09-23 19:25:47 -1000]: > > In any case, this has been a nasty issue to track down. I have surely traced it to the following code block in luci (by process of elimination): > > local fp > luci.http.setfilehandler( > function(meta, chunk, eof) > if not fp then > if meta and meta.name == "image" then > fp = io.open(image_tmp, "w") > else > fp = io.popen(restore_tmp, "w") > end > end > if chunk then > fp:write(chunk) > end > if eof then > fp:close() > end > end > ) > > > Here, "chunk" is a 2048 byte string, and the library calls are to nixio: > are you sure the nixio function is called? if fp is not set then io.open is called which should use libc fopen, so fp:write should be a wrapper around fwrite if the code really calls the nixio function below then there is no stdio involved, it directly writes to an fd > static int nixio_file_write(lua_State *L) { > int fd = nixio__checkfd(L, 1); > size_t len; > ssize_t sent; > const char *data = luaL_checklstring(L, 2, &len); > > if (lua_gettop(L) > 2) { > int offset = luaL_optint(L, 3, 0); > if (offset) { > if (offset < len) { > data += offset; > len -= offset; > } else { > len = 0; > } > } > > unsigned int wlen = luaL_optint(L, 4, len); > if (wlen < len) { > len = wlen; > } > } > > do { > sent = write(fd, data, len); > } while(sent == -1 && errno == EINTR); > if (sent >= 0) { > lua_pushinteger(L, sent); > return 1; > } else { > return nixio__perror(L); > } > } > > When I have time, I'll do a build against eglibc with a reduced BUFSIZ = 1024 (musl's default) and see if the problem is reproduced. > i think you should try to reproduce the bug with a minimal test-case where either stdio (io.*) is called or nixio only