[Bug libgcj/36218] New: [4.4 regression] libgcj causes stack overflow in jc1.exe

Several files in libgcj will cause jc1.exe to exhaust its stack space
allocation.

This can be worked around by compiling jc1.exe with -Wl,--stack,0x2000000,
which can be accomplished by including it in LDFLAGS when compiling.  (This
exact size is arbitrary; it's big enough to work, but perhaps much too big.)

The cause seems to be massive recursion between find_assert_locations() and
find_conditional_asserts().  I'm not sure if this is intended behavior.

If this is intended behavior, it's not clear to me what the right thing to do
to fix this is.  What negative consequences does increasing the default
allocation have?  Is it possible to adjust this limit at runtime, perhaps as
needed?


--
           Summary: [4.4 regression] libgcj causes stack overflow in jc1.exe
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: build, memory-hog
          Severity: critical
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aaronavay62 at aaronwl dot com
  GCC host triplet: i386-pc-mingw32
OtherBugsDependingO 36216
             nThis:


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

------- Comment #1 from aaronavay62 at aaronwl dot com  2008-05-12 11:03 -------
cipher.o at least fails for this reason.

I'm not sure when this last worked, but it at least worked sometime around
2004.


--

aaronavay62 at aaronwl dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.4.0 4.3.0 4.2.0


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

------- Comment #2 from dannysmith at users dot sourceforge dot net  2008-05-13 03:52 -------
(In reply to comment #0)
>  What negative consequences does increasing the default [stack]
> allocation have?  
Minimal really, for a single threaded program like jc1.exe.  We are just
reserving address space not actual memory.  In a multithreaded app, each thread
reserves the same amount of address space as the primary thread (by default,
but the default can be overiden), so too high a stack reserve for main thread
can limit what is available for others.  



Is it possible to adjust this limit at runtime, perhaps as
> needed?
>
No, not for main thread. It is built into the program header on MS windows.
GNAT also bumps stack reserve to 32 MB for "non-tasking" apps.  See
system-mingw.ads.  

In old days, 32 MB was default for win32 in gnu ld.
Danny


--


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

--

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
          Component|libgcj                      |tree-optimization
           Keywords|memory-hog                  |
            Summary|[4.4 regression] libgcj     |[4.4 regression] VRP causes
                   |causes stack overflow in    |stack overflow while
                   |jc1.exe                     |building libgcj
   Target Milestone|---                         |4.4.0


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

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-22 20:10 -------
VRP did not exist in 4.0.0.


--

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
      Known to work|                            |4.0.0
            Summary|[4.4 regression] VRP causes |[4.2/4.3/4.4 regression] VRP
                   |stack overflow while        |causes stack overflow while
                   |building libgcj             |building libgcj
   Target Milestone|4.4.0                       |4.3.1


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

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-06-06 14:59 -------
4.3.1 is being released, adjusting target milestone.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.1                       |4.3.2


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

------- Comment #5 from jsm28 at gcc dot gnu dot org  2008-06-08 16:15 -------
Subject: Bug 36218

Author: jsm28
Date: Sun Jun  8 16:14:33 2008
New Revision: 136563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136563
Log:
        PR tree-optimization/36218
        * Makefile.def (flags_to_pass): Add LDFLAGS_FOR_BUILD.
        * Makefile.tpl (EXTRA_BUILD_FLAGS): Define.
        (all prefix="build-"): Pass them to build-system sub-makes.
        * Makefile.in: Regenerate.

config:
        * config/mh-mingw (LDFLAGS): Define.

gcc:
        * configure.ac: Use LDFLAGS="${LDFLAGS_FOR_BUILD}" when running
        configure for the build system.
        (BUILD_LDFLAGS): Define.
        * configure: Regenerate.
        * Makefile.in (BUILD_LDFLAGS): Define to @BUILD_LDFLAGS@.

Modified:
    trunk/ChangeLog
    trunk/Makefile.def
    trunk/Makefile.in
    trunk/Makefile.tpl
    trunk/config/ChangeLog
    trunk/config/mh-mingw
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/configure
    trunk/gcc/configure.ac


--


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

------- Comment #6 from jsm28 at gcc dot gnu dot org  2008-06-08 16:37 -------
Note that a native build should be done to verify that my patch increases the
stack limit enough to fix this bug, before marking it fixed.


--


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

------- Comment #7 from aph at gcc dot gnu dot org  2008-06-11 10:49 -------
This isn't just a mingw bug.  It is also manifested in GNU/Linux if gcc itself
is built with -O0, as you need to do when debugging gcc.

There perhaps should be some limit to how far VRP goes before giving up.


--

aph at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aph at redhat dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-06-11 10:49:26
               date|                            |


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

------- Comment #8 from mmitchel at gcc dot gnu dot org  2008-06-13 21:41 -------
Ian --

Do you have any thoughts about this issue?

-- Mark


--

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com
           Priority|P3                          |P2


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

------- Comment #9 from ian at airs dot com  2008-06-14 05:59 -------
There aren't any obvious instructions on how to reproduce this bug.  Andrew,
which file(s) in libgcj do you see problems with?

Adding Diego to CC since VRP is his baby.


--

ian at airs dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dnovillo at gcc dot gnu dot
                   |                            |org


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

------- Comment #10 from aph at gcc dot gnu dot org  2008-06-14 06:27 -------
The only way I can find out which file in libgcj causes the stack overflow is
to try to build it again with an unoptimized gcc.  I can do so next week.


--


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

------- Comment #11 from dannysmith at users dot sourceforge dot net  2008-06-14 10:01 -------
(In reply to comment #6)
> Note that a native build should be done to verify that my patch increases the
> stack limit enough to fix this bug, before marking it fixed.
>

With this patch (8 mb stack reserve), native mingw32 jc1.exe (built with -O2)
is able to compile all libgcj objects on trunk and 4_3-branch.

Danny


--


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

------- Comment #12 from aaronavay62 at aaronwl dot com  2008-06-14 15:43 -------
(In reply to comment #9)
> There aren't any obvious instructions on how to reproduce this bug.  Andrew,
> which file(s) in libgcj do you see problems with?

If you build libjava on a Win32 (mingw32 or Cygwin) target without altering
ld's default stack reserve, cipher.o will fail to build with a stack overflow.


--


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

------- Comment #13 from aaronavay62 at aaronwl dot com  2008-07-14 08:03 -------
Joseph's patch doesn't work for me, because the --stack parameter never makes
it to the link line for some reason, and I get the same crash building
cipher.o.  This is the relevant output of bootstrap:

rm -f jc1.exe
/mingw/src/gccf/./prev-gcc/xgcc -B/mingw/src/gccf/./prev-gcc/
-B/mingw/i386-pc-mingw32/bin/  -g -O2 -D__USE_MINGW_ACCESS -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros
                             -Wno-overlength-strings -Werror -fno-common
-DHAVE
_CONFIG_H  -o jc1.exe \
                java/class.o java/decl.o java/expr.o java/constants.o
java/lang.o java/typeck.o java/except.o java/verify-glue.o java/verify-impl.o
java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o
java/mangle_name.o java/builtins.o java/resource.o java/jcf-depend.o
java/jcf-path.o java/boehm.o java/java-gimplify.o main.o tree-browser.o
libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -L../zlib -lz
../libcpp/libcpp.a ./../intl/libintl.a  ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a attribs.o -L/mingw/src/gmp-mpfr/root/lib
-L/mingw/src/gmp-mpfr/root/lib -lmpfr -lgmp

I don't know if there is something particular to the way I've configured that
might be making this break for me.  As an additional data point, for some
reason when I tried overriding LDFLAGS previously, the stack parameter also did
not propagate properly to jc1.exe, although it propagated just fine to some of
the other link lines outside of Java.

../svn/configure --enable-languages=c,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-libgcj --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-libstdcxx-debug --enable-concept-checks
--enable-version-specific-runtime-libs --prefix=/mingw
--with-gmp=/mingw/src/gmp-mpfr/root --with-mpfr=/mingw/src/gmp-mpfr/root
--with-libiconv-prefix=/mingw/src/libiconv/root
make


--

aaronavay62 at aaronwl dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2008-06-11 10:50:09         |2008-07-14 08:03:23
               date|                            |


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

------- Comment #14 from aph at gcc dot gnu dot org  2008-07-30 09:23 -------
This patch limits recursion in tree-vrp.

Index: tree-vrp.c
===================================================================
--- tree-vrp.c  (revision 136670)
+++ tree-vrp.c  (working copy)
@@ -4049,6 +4049,8 @@
    the predicate operands, an assert location node is added to the
    list of assertions for the corresponding operands.  */

+static size_t depth;
+
 static bool
 find_conditional_asserts (basic_block bb, tree last)
 {
@@ -4062,6 +4064,10 @@
   need_assert = false;
   bsi = bsi_for_stmt (last);

+  depth++;
+  if (depth > 500)
+    goto ret;
+
   /* Look for uses of the operands in each of the sub-graphs
      rooted at BB.  We need to check each of the outgoing edges
      separately, so that we know what kind of ASSERT_EXPR to
@@ -4121,6 +4127,8 @@
   FOR_EACH_SSA_TREE_OPERAND (op, last, iter, SSA_OP_USE)
     SET_BIT (found_in_subgraph, SSA_NAME_VERSION (op));

+ ret:
+  depth--;
   return need_assert;
 }



--


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

------- Comment #15 from rguenth at gcc dot gnu dot org  2008-08-22 19:28 -------
This should be fixed on the trunk by

2008-08-20  Richard Guenther  <rguenther@...>

        * tree-vrp.c (found_in_subgraph): Remove.
        (live): New global static.
        (live_on_edge): New function.
        (blocks_visited): Remove.
        (register_edge_assert_for_2): Use live_on_edge.
        (find_conditional_asserts): Remove code dealing with
        found_in_subgraph.  Do not walk the CFG.
        (find_switch_asserts): Likewise.
        (find_assert_locations_1): Renamed from find_assert_locations.
        Move finding assert locations for conditional and switch
        statements first.  Update live bitmap.  Do not walk the CFG.
        (find_assert_locations): New function.
        (insert_range_assertions): Remove entry of CFG walk.
        Adjust call to find_assert_locations.


can someone verify this?  Thanks.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

------- Comment #16 from aaronavay62 at aaronwl dot com  2008-08-23 18:06 -------
(In reply to comment #15)
> This should be fixed on the trunk by
> 2008-08-20  Richard Guenther  <rguenther@...>

> can someone verify this?  Thanks.

Yes and no.

On revision 139510 (2008-08-23), the compilation of cipher.lo is successful in
a normal build, so I presume that the VRP problem has been fixed.  Yay!

However, there is a new (since April 2008) stack overflow now in HTML_401F.lo.
This one does not seem to be VRP-related, as -fno-tree-vrp does not seem to
help.  It does, however, compile with -O0.  Here is the backtrace:

#0  0x00a61805 in htab_find_slot_with_hash (htab=0x5745038, element=0x83060,
    hash=13718576, insert=INSERT) at ../../svn/libiberty/hashtab.c:610
#1  0x00a61a82 in htab_find_slot (htab=0x5745038, element=0x83060,
    insert=INSERT) at ../../svn/libiberty/hashtab.c:678
#2  0x0076562a in set_livein_block (var=0x68aa180, bb=0x54c3dc0)
    at ../../svn/gcc/tree-into-ssa.c:503
#3  0x00766ae1 in prepare_block_for_update (bb=0x54c3dc0,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2364
#4  0x00766cf0 in prepare_block_for_update (bb=0x54c3d00,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#5  0x00766cf0 in prepare_block_for_update (bb=0x54c3c00,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
...
#10851 0x00766cf0 in prepare_block_for_update (bb=0x4f63600,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#10852 0x00766cf0 in prepare_block_for_update (bb=0x4f63580,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#10853 0x00766cf0 in prepare_block_for_update (bb=0x4f63500,
    insert_phi_p=1 '\001') at ../../svn/gcc/tree-into-ssa.c:2450
#10854 0x00769e62 in update_ssa (update_flags=2048)
    at ../../svn/gcc/tree-into-ssa.c:3230
#10855 0x00762164 in compute_may_aliases ()
    at ../../svn/gcc/tree-ssa-alias.c:1842
#10856 0x0052644d in execute_function_todo (data=0x100001)
    at ../../svn/gcc/passes.c:943
#10857 0x005265a0 in do_per_function (
    callback=0x52629c <execute_function_todo>, data=0x100001)
    at ../../svn/gcc/passes.c:837
#10858 0x00526670 in execute_todo (flags=1048577)
    at ../../svn/gcc/passes.c:1021
#10859 0x00526954 in execute_one_pass (pass=0xb05150)
    at ../../svn/gcc/passes.c:1297
#10860 0x00526b48 in execute_pass_list (pass=0xb05150)
    at ../../svn/gcc/passes.c:1323
#10861 0x00526b5b in execute_pass_list (pass=0xb04f10)
    at ../../svn/gcc/passes.c:1324
#10862 0x00759fb0 in tree_rest_of_compilation (fndecl=0x28c6c80)
    at ../../svn/gcc/tree-optimize.c:418
#10863 0x0058796f in cgraph_expand_function (node=0x47acc80)
    at ../../svn/gcc/cgraphunit.c:1039
#10864 0x0058968a in cgraph_optimize () at ../../svn/gcc/cgraphunit.c:1101
#10865 0x00443615 in java_parse_file (set_yydebug=0)
    at ../../svn/gcc/java/jcf-parse.c:1961
#10866 0x0047907d in toplev_main (argc=32, argv=0x31934e8)
    at ../../svn/gcc/toplev.c:959
#10867 0x0040124b in __mingw_CRTStartup ()
#10868 0x00401298 in mainCRTStartup ()

Should I open a new PR for this different stack overflow, and close this one?

I still have not had a chance to see why Joseph's change to LDFLAGS to make
MinGW use the same stack allocation as Linux when building GCC does not
propagate into libjava.  Once that is fixed, this entire catagory of
MinGW-specific problems should go away.

So alternately we could close this one, and open a new one just for the LDFLAGS
issue.


--

aaronavay62 at aaronwl dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2008-07-14 08:03:23         |2008-08-23 18:06:02
               date|                            |


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

------- Comment #17 from jsm28 at gcc dot gnu dot org  2008-08-27 22:04 -------
4.3.2 is released, changing milestones to 4.3.3.


--

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


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

------- Comment #18 from rguenth at gcc dot gnu dot org  2008-09-20 15:09 -------
Please open a new report for the SSA update problem.  Back to NEW for this
PR, fixed on the trunk.  *-*-mingw* is not in the list of primary or secondary
platforms, so P4.


--

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
      Known to work|4.0.0                       |4.0.0 4.4.0
           Priority|P2                          |P4
   Last reconfirmed|2008-08-23 18:06:02         |2008-09-20 15:09:14
               date|                            |
            Summary|[4.2/4.3/4.4 regression] VRP|[4.2/4.3 Regression] VRP
                   |causes stack overflow while |causes stack overflow while
                   |building libgcj             |building libgcj
   Target Milestone|4.3.3                       |4.2.5


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