From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2493 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: LLVM testsuite, close-stderr.ll hangs Date: Mon, 17 Dec 2012 11:58:29 -0500 Message-ID: <20121217165829.GT20323@brightrain.aerifal.cx> References: <50CEFC0B.70307@ojab.ru> 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 1355763523 19808 80.91.229.3 (17 Dec 2012 16:58:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Dec 2012 16:58:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2494-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 17 17:58:58 2012 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 1Tke1p-0004s6-Nz for gllmg-musl@plane.gmane.org; Mon, 17 Dec 2012 17:58:57 +0100 Original-Received: (qmail 1782 invoked by uid 550); 17 Dec 2012 16:58:43 -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 1766 invoked from network); 17 Dec 2012 16:58:43 -0000 Content-Disposition: inline In-Reply-To: <50CEFC0B.70307@ojab.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2493 Archived-At: On Mon, Dec 17, 2012 at 03:03:39PM +0400, ojab wrote: > On glibc this command exits with code 1, on musl it hangs. strace > output can be found in the attached files. > [...] > 28321 write(2, "LLVM ERROR: IO failure on output stream.\n", 41) = -1 EBADF (Bad file number) > 28321 pause( The only way pause() is called from exit() is when the exit lock is already held. There are 3 basic ways this could happen: 1. Memory corruption that overwrote the lock variable. 2. Another thread holding the lock indefinitely (e.g. deadlock an an atexit handler). 3. Recursive call to exit (i.e. calling exit from an atexit handler or a signal handler. Since I don't see any threads in the strace, I'm ruling out #2. #1 is definitely an option, but I suspect what's going on is #3, in which case it's an llvm bug. Calling exit more than once is undefined behavior; in particular, atexit handlers or global destructors cannot call exit. Rich