From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23495 invoked by alias); 26 Jun 2012 14:57:12 -0000 Received: (qmail 23485 invoked by uid 22791); 26 Jun 2012 14:57:11 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_IB X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jun 2012 14:56:58 +0000 From: "dje at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/53779] Bootstrap hangs waiting for a lock Date: Tue, 26 Jun 2012 14:57:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-06/txt/msg01736.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 --- Comment #1 from Andreas Schwab 2012-06-26 14:55:34 UTC --- Try running it under valgrind. Your patch is apparently causing a memory corruption, and the SIGABRT handler tries to call back into malloc/free, which cannot work. Most likely target_cost_data is freed twice. --- Comment #2 from David Edelsohn 2012-06-26 14:56:32 UTC --- Alan and my patch was to libjava and did not change anything in the common support for atomics. Unless the build is using libjava at that point, there is no way for the libjava locks.h patch to affect this. This may be due to some indirect change in the process memory layout after Steven's change. But the real problem appears to libc free() crashing in a call from var-tracking. libc raises a signal, GCC catching it and tries to print a pretty error and cleanup before exiting. The cleanup calls free() again and hangs. Is there some memory problem in var-tracking or an underlying data structure that was exposed by Steven's change? Some weird page crossing or some dangling pointer that accidentally pointed to valid memory before the process layout changed?