From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4277 invoked by alias); 26 Jun 2012 13:56:11 -0000 Received: (qmail 4266 invoked by uid 22791); 26 Jun 2012 13:56:10 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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 13:55:56 +0000 From: "wschmidt at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/53779] New: Bootstrap hangs waiting for a lock Date: Tue, 26 Jun 2012 13:56:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: wschmidt 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: 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/msg01728.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779 Bug #: 53779 Summary: Bootstrap hangs waiting for a lock Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned@gcc.gnu.org ReportedBy: wschmidt@gcc.gnu.org CC: amodra@gmail.com, bergner@vnet.ibm.com, dje@gcc.gnu.org, stevenb.gcc@gmail.com Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Created attachment 27706 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27706 Patch that exhibits the problem I've run into a couple of situations recently where bootstrap gets hung up during stage2 on a locking problem in the runtime memory support. This doesn't occur with the current code in the trunk, but has occurred for me on two unrelated working patches. For the current patch I'm working on, I bisected the problem to r188838, which makes little sense. That revision is: 2012-06-20 Steven Bosscher * system.h: Poison ASM_OUTPUT_IDENT and IDENT_ASM_OP. This doesn't seem likely to be directly related, but it is consistent that all revisions prior to that bootstrap with this patch and all revisions afterwards don't. I wonder whether revision 188829 could be involved: 2012-06-20 David Edelsohn Alan Modra * sysdep/powerpc/locks.h (compare_and_swap): Use GCC atomic intrinsics. (release_set): Same. (compare_and_swap_release): Same. (read_barrier): Same. (write_barrier): Same. and 188830 which contains a one-line fix for the above. It seems possible that there is some sort of issue there that only appears when the stars align just so. In both cases where I've seen this, the problem comes while compiling tree-vect-stmts.c for stage 2. In one working patch, I made changes to this part, while in the other I did not. When I attach to the hung process, this is the stack trace I see: #0 0x00000400002ff298 in .__lll_lock_wait_private () from /lib64/power7/libc.so.6 #1 0x0000040000285e30 in .__libc_free () from /lib64/power7/libc.so.6 #2 0x0000000011095278 in operator delete (ptr=) at ../../../../libstdc++-v3/libsupc++/del_op.cc:49 #3 0x000000001105fee0 in deallocate (__p=, this=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/ext/new_allocator.h:98 #4 std::string::_Rep::_M_destroy (this=, __a=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/bits/basic_string.tcc:424 #5 0x00000000110623ac in _M_dispose (__a=, this=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/bits/basic_string.h:236 #6 std::basic_string, std::allocator >::~basic_string (this=, __in_chrg=) at /usr/src/packages/BUILD/gcc-4.3.4-20091019/obj-powerpc64-suse-linux/powerpc64-suse-linux/libstdc++-v3/include/bits/basic_string.h:494 #7 0x000004000023baac in .__run_exit_handlers () from /lib64/power7/libc.so.6 #8 0x000004000023bb28 in .exit () from /lib64/power7/libc.so.6 #9 0x0000000010dc9c88 in ._ZL30diagnostic_action_after_outputP18diagnostic_cont extP15diagnostic_info.isra.2 () #10 0x0000000010dc9e8c in ._Z28diagnostic_report_diagnosticP18diagnostic_contextP15diagnostic_info () #11 0x0000000010dcaa20 in ._Z14internal_errorPKcz () #12 0x0000000010817fbc in ._ZL12crash_signali () #13 #14 0x0000040000238100 in .raise () from /lib64/power7/libc.so.6 #15 0x0000040000239dc0 in .abort () from /lib64/power7/libc.so.6 #16 0x0000040000278924 in .__libc_message () from /lib64/power7/libc.so.6 #17 0x0000040000280428 in .malloc_printerr () from /lib64/power7/libc.so.6 #18 0x00000400002808c8 in .malloc_consolidate () from /lib64/power7/libc.so.6 #19 0x0000040000281fc8 in ._int_free () from /lib64/power7/libc.so.6 #20 0x0000040000285d30 in .__libc_free () from /lib64/power7/libc.so.6 #21 0x0000000010410b2c in ._Z16empty_alloc_poolP14alloc_pool_def () #22 0x0000000010410bb8 in ._Z15free_alloc_poolP14alloc_pool_def () #23 0x0000000010a8a174 in ._ZL11vt_finalizev () #24 0x0000000010aa0290 in ._Z22variable_tracking_mainv () #25 0x00000000107454f8 in ._Z16execute_one_passP8opt_pass () #26 0x00000000107459d4 in ._Z17execute_pass_listP8opt_pass () #27 0x00000000107459ec in ._Z17execute_pass_listP8opt_pass () #28 0x00000000107459ec in ._Z17execute_pass_listP8opt_pass () #29 0x000000001049ced8 in ._ZL15expand_functionP11cgraph_node () #30 0x000000001049f664 in ._Z7compilev () It appears to be attempting to handle an error of some sort (perhaps a double free?) when it gets hung. Note there are two calls to __libc_free on the stack which I suppose could lead to a locking problem. It seems very possible that I have a problem with memory management in the patch, but if so it should be handled more gracefully... To hopefully allow the problem to be reproduced, I'm attaching the patch I'm working on, which can be applied at r188838. Thanks for any ideas!