From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2494 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 12:22:27 -0500 Message-ID: <20121217172227.GU20323@brightrain.aerifal.cx> References: <50CEFC0B.70307@ojab.ru> <20121217165829.GT20323@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 1355764960 2538 80.91.229.3 (17 Dec 2012 17:22:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Dec 2012 17:22:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2495-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 17 18:22:55 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 1TkeOz-0002o8-3Y for gllmg-musl@plane.gmane.org; Mon, 17 Dec 2012 18:22:53 +0100 Original-Received: (qmail 15688 invoked by uid 550); 17 Dec 2012 17:22:39 -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 15680 invoked from network); 17 Dec 2012 17:22:39 -0000 Content-Disposition: inline In-Reply-To: <20121217165829.GT20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2494 Archived-At: On Mon, Dec 17, 2012 at 11:58:29AM -0500, Rich Felker wrote: > 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. To track this down, you could run under gdb and just interrupt the program and look at a backtrace once it hangs. This should make it clear whether exit was called recursively. Rich