From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6193 Path: news.gmane.org!not-for-mail From: Scott Valentine Newsgroups: gmane.linux.lib.musl.general Subject: Re: LUA + musl, garbage collection issue? Date: Tue, 23 Sep 2014 20:14:51 -1000 Message-ID: References: <20140924055001.GA21835@port70.net> 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 1411539346 30781 80.91.229.3 (24 Sep 2014 06:15:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Sep 2014 06:15:46 +0000 (UTC) Cc: Szabolcs Nagy , Justin Cormack To: musl@lists.openwall.com Original-X-From: musl-return-6206-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 24 08:15:40 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 1XWfrV-0005gp-7L for gllmg-musl@plane.gmane.org; Wed, 24 Sep 2014 08:15:37 +0200 Original-Received: (qmail 32325 invoked by uid 550); 24 Sep 2014 06:15:06 -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 32305 invoked from network); 24 Sep 2014 06:15:06 -0000 X-TMN: [e9vUky3MvAv32/tEw8grjMihDzM8TOz4] 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; ; ) In-Reply-To: <20140924055001.GA21835@port70.net> X-OriginalArrivalTime: 24 Sep 2014 06:14:53.0911 (UTC) FILETIME=[DB3EAE70:01CFD7BE] Xref: news.gmane.org gmane.linux.lib.musl.general:6193 Archived-At: On Wednesday, September 24, 2014 07:50:01 AM Szabolcs Nagy wrote: > * 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 You are correct... My brain must be getting tired. > > 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 Yes, now that you've pointed out the above, I have something I can work with. I should be able to write a pure lua script to try and reproduce the problem. -Scott V. --