[Bug bootstrap/53779] New: Bootstrap hangs waiting for a lock

["wschmidt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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  <steven@gcc.gnu.org>

         * 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  <dje.gcc@gmail.com>
            Alan Modra  <amodra@gmail.com>

            * 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=<optimized out>)
    at ../../../../libstdc++-v3/libsupc++/del_op.cc:49
#3  0x000000001105fee0 in deallocate (__p=<optimized out>, 
    this=<optimized out>)
    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=<optimized out>, __a=<optimized out>)
    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=<optimized out>, 
    this=<optimized out>)
    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<char, std::char_traits<char>, std::allocator<char>
>::~basic_string (this=<optimized out>, __in_chrg=<optimized out>)
    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 <signal handler called>
#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!