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

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

[wschmidt at gcc dot 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!

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

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 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.

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

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 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 <dje at gcc dot gnu.org> 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?

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

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #3 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-26 15:07:33 UTC ---
I wonder if the recent changes to var-tracking.c contain the possibility for a
double-free.

I think it's not directly due to my patch for the following reason:  This has
happened on two different working patches recently.  One makes memory
allocation changes in the vectorizer; the other made memory allocation changes
in IVOPTS.  In both cases, the stack was nearly the same -- blowing up when
freeing some memory in the var-tracking phase.  In one case it was a call to
free_alloc_pool, in the other a call to delete_htab.

Copying Alexandre for his opinion.  What do you think?

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

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2012-06-26 15:58:40 UTC ---
(In reply to comment #3)
> I wonder if the recent changes to var-tracking.c contain the possibility for a
> double-free.
> 

PR 53706.

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

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53779

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #5 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-26 16:25:08 UTC ---
Thanks, H.J.  Definitely the same problem.

*** This bug has been marked as a duplicate of bug 53706 ***