United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6901572 JVM 1.6.16 crash on loops: assert(has_node(i),"")
6901572 : JVM 1.6.16 crash on loops: assert(has_node(i),"")

Details
Type:
Bug
Submit Date:
2009-11-16
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs16,hs17
Fixed Versions:
hs17

Related Reports
Backport:
Backport:

Sub Tasks

Description
From http://forums.sun.com/thread.jspa?threadID=5414815:

While testing JVM 1.6.16 before using it for our application i've found a strange bug.

The VM ALWAYS crash when i execute this quite simple sample of code.

Do anyone reproduce the problem or has any clue of it's reason ?

package crashVM;
 
public class CrashTest {
 
 /**
  * @param args
  */
 public static void main(String[] args) {
   for (int i = 0; i < 2; i++)
     NestedLoop();
 }
 
 public static long NestedLoop() {
   final int n = 50;
 
   long startTime = System.currentTimeMillis();
 
   int x = 0;
   for (int a = 0; a < n; a++)
     for (int b = 0; b < n; b++)
       for (int c = 0; c < n; c++)
         for (int d = 0; d < n; d++)
           for (int e = 0; e < n; e++)
             for (int f = 0; f < n; f++)
               x++;
 
   long stopTime = System.currentTimeMillis();
 
   return stopTime - startTime;
 }
 
}



Thanx !

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b22f86d1740
                                     
2009-12-02
EVALUATION

The culprit is the dead code related to "x++". In the first round of loop optimization, "x++" is
used by a safepoint node and everything is set up for "x++" and related phis. However, the loop
optimizer will remove the loop safepoints for the counted loops, and then "x++" and related phis
become a big dead circle. In the second round of loop optimizations, the controls of those dead
nodes could not be set up and any operation on those nodes may cause problem.

IterGVN could not detect such big dead loop (circle) so those nodes could not be optimized away.

I have a fix (suggested by Vladimir) to fix the problem by adding something like
eliminate_dead_nodes();
 // Cleanup any modified bits
 _igvn.optimize();

in build_and_optimize in PhaseIdealLoop.
eliminate_dead_nodes essentially detects all unreachable nodes and remove them.

Note1: in the test case, if you make "x" somehow useful (e.g. return (long) x), C2 will not crash.
Note2: C2 and C1 performance (timings):
[cf231476@pathscale ~]$ /home/cf231476/refworkload/vm/bin/java  -client  crashVM/CrashTest
32172
32180
[cf231476@pathscale ~]$ /home/cf231476/refworkload/vm/bin/java  -server  crashVM/CrashTest
734
717
                                     
2009-11-19
EVALUATION

This is a regression from 6u14 b01 (from hs14 b06). 
It started from the following changeset:
/net/prt-archiver.sfbay.sun.com/data/jprt/archive/2008/09/2008-09-17-200034.never.6384206
Looks to me "policy_do_remove_empty_loop" is fine but it passes if I disable 
"policy_do_remove_empty_loop".

The assertion is for a phi node whose control was not set, and thus get_ctrl hot
has_node(i) assert.
                                     
2009-11-18
EVALUATION

It also happens with HS17 b05 on 32-bit.  The backtrace is:

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/loopnode.hpp:568
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/export/home/twisti/hotspot-comp/hotspot/src/share/vm/opto/loopnode.hpp:568), pid=20568, tid=8
#  Error: assert(has_node(i),"")
#
# JRE version: 7.0-b59
# Java VM: OpenJDK Server VM (17.0-b05-internal-jvmg mixed mode solaris-x86 )
# An error report file with more information is saved as:
# /export/home/twisti/hotspot-comp/hs_err_pid20568.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 8
Dumping core ...
t@8 (l@8) signal ABRT (Abort) in _lwp_kill at 0xc8563935
0xc8563935: _lwp_kill+0x0015:	jae      _lwp_kill+0x23	[ 0xc8563943, .+0xe ]
Current function is os::abort
 1811       ::abort(); // dump core (for debugging)
(dbx) where        
current thread: t@8
  [1] _lwp_kill(0x8, 0x6, 0x805fbd04, 0xc855bfda), at 0xc8563935 
  [2] thr_kill(0x8, 0x6, 0x805fbd04, 0xc850b02e), at 0xc855bffc 
  [3] raise(0x6, 0x0, 0x805fbd54, 0xc84e223a), at 0xc850b03a 
  [4] abort(0x7, 0xc98c80cc, 0xc91de51c, 0x805f0038, 0xc8dcafa4, 0xc99a4880), at 0xc84e225a 
=>[5] os::abort(dump_core = true), line 1811 in "os_solaris.cpp"
  [6] VMError::report_and_die(this = 0x805fbed8), line 866 in "vmError.cpp"
  [7] report_assertion_failure(file_name = 0xc96dd1b2 "/export/home/twisti/hotspot-comp/hotspot/src/share/vm/opto/loopnode.hpp", line_no = 568, message = 0xc96dd1fa "assert(has_node(i),"")"), line 173 in "debug.cpp"
  [8] PhaseIdealLoop::get_ctrl(this = 0x805fcfa4, i = 0x81c2e34), line 568 in "loopnode.hpp"
  [9] PhaseIdealLoop::get_early_ctrl(this = 0x805fcfa4, n = 0x80bdbb8), line 65 in "loopnode.cpp"
  [10] PhaseIdealLoop::set_early_ctrl(this = 0x805fcfa4, n = 0x80bdbb8), line 109 in "loopnode.cpp"
  [11] IdealLoopTree::counted_loop(this = 0x81ac380, phase = 0x805fcfa4), line 1324 in "loopnode.cpp"
  [12] IdealLoopTree::counted_loop(this = 0x81ac3d8, phase = 0x805fcfa4), line 1359 in "loopnode.cpp"
  [13] IdealLoopTree::counted_loop(this = 0x81ac430, phase = 0x805fcfa4), line 1359 in "loopnode.cpp"
  [14] IdealLoopTree::counted_loop(this = 0x81ac488, phase = 0x805fcfa4), line 1359 in "loopnode.cpp"
  [15] IdealLoopTree::counted_loop(this = 0x81ac4e0, phase = 0x805fcfa4), line 1359 in "loopnode.cpp"
  [16] IdealLoopTree::counted_loop(this = 0x81a9d78, phase = 0x805fcfa4), line 1359 in "loopnode.cpp"
  [17] PhaseIdealLoop::build_and_optimize(this = 0x805fcfa4, do_split_ifs = false), line 1559 in "loopnode.cpp"
  [18] PhaseIdealLoop::PhaseIdealLoop(this = 0x805fcfa4, igvn = CLASS, do_split_ifs = false), line 703 in "loopnode.hpp"
  [19] Compile::Optimize(this = 0x805fe420), line 1556 in "compile.cpp"
  [20] Compile::Compile(this = 0x805fe420, ci_env = 0x805fe9c8, compiler = 0x8179210, target = 0x81fee08, osr_bci = -1, subsume_loads = true, do_escape_analysis = true), line 620 in "compile.cpp"
  [21] C2Compiler::compile_method(this = 0x8179210, env = 0x805fe9c8, target = 0x81fee08, entry_bci = -1), line 112 in "c2compiler.cpp"
  [22] CompileBroker::invoke_compiler_on_method(task = 0x81aa0b8), line 1543 in "compileBroker.cpp"
  [23] CompileBroker::compiler_thread_loop(), line 1389 in "compileBroker.cpp"
  [24] compiler_thread_entry(thread = 0x818dc00, __the_thread__ = 0x818dc00), line 2746 in "thread.cpp"
  [25] JavaThread::thread_main_inner(this = 0x818dc00), line 1382 in "thread.cpp"
  [26] JavaThread::run(this = 0x818dc00), line 1366 in "thread.cpp"
  [27] java_start(thread_addr = 0x818dc00), line 1019 in "os_solaris.cpp"
  [28] _thrp_setup(0x81163200), at 0xc855e3f3 
  [29] _lwp_start(0x8, 0x6, 0x805fbd04, 0xc855bfda, 0x2, 0xc85f1000), at 0xc855e680
                                     
2009-11-16
EVALUATION

This should be a bug in policy_do_remove_empty_loop. I am looking into it.
                                     
2009-11-16



Hardware and Software, Engineered to Work Together