United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6788347 C2Compiler crash 6u7
JDK-6788347 : C2Compiler crash 6u7

Details
Type:
Bug
Submit Date:
2008-12-23
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2009-01-26
Component:
hotspot
OS:
solaris_10
Sub-Component:
compiler
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u17,6u7
Fixed Versions:
6u11-rev (b07)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Deutsche Bank(Australia) sees a crash in C2Compiler, 6.0u7.
Workaround would be exclude method and implemented.

The stack trace looks similar to 6687945 but there is no other info to confirm the same.

[7] __sighndlr(0xb, 0x7297d940, 0x7297d688, 0xfe9a5544, 0x0, 0x1), at 0xff2c4abc
---- called from signal handler with signal 11 (SIGSEGV) ------
[8] PhaseIdealLoop::build_loop_late_post(0x0, 0x0, 0x13314368, 0x7297dd14, 0x1430e5c0, 0x13ab3630), at 0xfe8cf0ac
[9] PhaseIdealLoop::build_loop_late(0x7297dd14, 0x7297dc70, 0x7297dc50, 0x7297dc60, 0x0, 0x322), at 0xfe979a70
[10] PhaseIdealLoop::PhaseIdealLoop(0x7297dd14, 0x7297ec58, 0x0, 0x0, 0xff0ea000, 0xff116984), at 0xfee19734
[11] Compile::Optimize(0x7297f450, 0x1a2610, 0x7297dd14, 0xff122b10, 0x7297dfe8, 0x28), at 0xfe9ad0e0
[12] Compile::Compile(0x7297f450, 0x14182d44, 0x2daa8, 0x1417ad50, 0x7297fa8c, 0x1417b328), at 0xfebd3050
[13] C2Compiler::compile_method(0x2daa8, 0x7297fa8c, 0x1454d290, 0xffffffff, 0xfefe4788, 0xff0ea000), at 0xfe9a73d4
[14] CompileBroker::invoke_compiler_on_method(0x3e7520, 0xe7c00, 0xa2e, 0x0, 0xfe9a7358, 0x1aac00), at 0xfe9a8168
[15] CompileBroker::compiler_thread_loop(0x0, 0xff120ff0, 0x1aac00, 0x1a2550, 0x2c800, 0x2c800), at 0xfea25064
[16] JavaThread::thread_main_inner(0x1aac00, 0x1ab168, 0xd, 0xf, 0xff0ea000, 0x0), at 0xfef17674
[17] java_start(0x1aac00, 0xb, 0x6284, 0xff0ea000, 0xff05d875, 0xff121914), at 0xfee6d148
(dbx) x 0x1454d290/2X
0x1454d290:      0xff10a7dc 0x001ba12c
(dbx) x 0x001ba12c
0x001ba12c:      0xf9290240
(dbx) print16 0xf9290240
au/com/asx/fix/omadapter/translator/OMFIXTranslator.translateToOMAmendOrder(Lcom/cameronsystems/fix/message/IFIXMessage;Lcom/cameronsystems/util/market/IOrder;Lcom/cameronsystems/fix/asxclickadapter/FixSessionId;)Lau/com/asx/fix/omadapter/translator/FIXOMAmendOrder;

And maybe pure coincidence, there is another compilation underway.
current thread: t@14
=>[1] PhaseChaitin::build_ifg_physical(0x7237ea0c, 0x2, 0x5455555, 0xff119df8, 0x0, 0xa), at 0xfe964d6c
[2] PhaseChaitin::Register_Allocate(0x7237ea0c, 0x0, 0x7237f3d0, 0xff0ea000, 0x13cd0c9c, 0x13cd08a8), at 0xfe98758c
[3] Compile::Code_Gen(0x0, 0x7237f3d0, 0xff0ea000, 0x7237eab0, 0xfe986aec, 0x0), at 0xfe989eb0
[4] Compile::Compile(0x7237f3d0, 0x1441afac, 0x2daa8, 0x14412fb8, 0x7237fa0c, 0x144152c0), at 0xfebd30a4
[5] C2Compiler::compile_method(0x2daa8, 0x7237fa0c, 0x143f3730, 0xffffffff, 0xfefe4788, 0xff0ea000), at 0xfe9a73d4
[6] CompileBroker::invoke_compiler_on_method(0x96d720, 0xe7c00, 0xa2f, 0x0, 0xfe9a7358, 0x1ac800), at 0xfe9a8168
[7] CompileBroker::compiler_thread_loop(0x0, 0xff120ff0, 0x1ac800, 0x1a2550, 0x2c800, 0x2c800), at 0xfea25064
[8] JavaThread::thread_main_inner(0x1ac800, 0x1acc30, 0xe, 0xf, 0xff0ea000, 0x0), at 0xfef17674
[9] java_start(0x1ac800, 0xc, 0x6284, 0xff0ea000, 0xff05d875, 0xff121914), at 0xfee6d148

(dbx) x 0x143f3730/2X
0x143f3730:      0xff10a7dc 0x00221a74
(dbx) x 0x00221a74
0x00221a74:      0xf9282a30
(dbx) print16 0xf9282a30
au/com/asx/fix/omadapter/translator/OMFIXTranslator.translateAmendQuantities(Lcom/cameronsystems/fix/message/IFIXMessage;Lcom/cameronsystems/util/market/IOrder;Lau/com/asx/jom/structure/hv_alter_trans_t;)Z

The files are at /net/cores.central/cores/70389736/suncase_70389736 if you want a quick look.

The relationship b/w OMFIXTranslator.translateToOMAmendOrder and translateAmendQuantities, translateToOMAmendOrder invokes translateAmendQuantities, thats all.

Cu is reluctant to test with 6.0u11.

And getting OMFIXTranslator.translateToOMAmendOrder to fail in
compilation in their test environment proves to be quite difficult.

                                    

Comments
SUGGESTED FIX

Email from Tom Rodriguez

So I finally tracked this down and it's a new bug.  I was able to replay the compile from the core file to reproduce the bug but it didn't reproduce with recent versions of hotspot, so I started patching intermediate builds with the reply support until I hit a build where it went away.  It turns out that the RPO parsing changes made it disappear but I didn't believe it really fixed it.  I just finished debugging it and it turns out it's TypeKlassPtr version of the special case logic for TypeInstPtr when interface and concrete types meet at phis.  We have an interface klass typed Phi with concrete inputs that are some real klass that implements that interface but when we call Value() on it we return top for it because the type system thinks they are unrelated.  This causes the graph to become malformed and breaks the dominance relationship with it's uses.  Fui Shien (or Herrick), could you file a new bug for this?

The fix is something like:

diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp
--- a/src/share/vm/opto/type.cpp
+++ b/src/share/vm/opto/type.cpp
@@ -2471,6 +2471,8 @@ const Type *TypeOopPtr::filter( const Ty
  const Type* ft = join(kills);
  const TypeInstPtr* ftip = ft->isa_instptr();
  const TypeInstPtr* ktip = kills->isa_instptr();
+  const TypeKlassPtr* ftkp = ft->isa_klassptr();
+  const TypeKlassPtr* ktkp = kills->isa_klassptr();

  if (ft->empty()) {
    // Check for evil case of 'this' being a class and 'kills' expecting an
@@ -2483,6 +2485,8 @@ const Type *TypeOopPtr::filter( const Ty
    // into a Phi which "knows" it's an Interface type we'll have to
    // uplift the type.
    if (!empty() && ktip != NULL && ktip->is_loaded() && ktip->klass()->is_interface())
+      return kills;             // Uplift to interface
+    if (!empty() && ktkp != NULL && ktkp->klass()->is_loaded() && ktkp->klass()->is_interface())
      return kills;             // Uplift to interface

    return Type::TOP;           // Canonical empty value

diff --git a/src/share/vm/opto/cfgnode.cpp b/src/share/vm/opto/cfgnode.cpp
--- a/src/share/vm/opto/cfgnode.cpp
+++ b/src/share/vm/opto/cfgnode.cpp
@@ -858,6 +858,7 @@ const Type *PhiNode::Value( PhaseTransfo
  // convert the one to the other.
  const TypePtr* ttp = _type->make_ptr();
  const TypeInstPtr* ttip = (ttp != NULL) ? ttp->isa_instptr() : NULL;
+  const TypeInstPtr* ttkp = (ttp != NULL) ? ttp->isa_klassptr() : NULL;
  bool is_intf = false;
  if (ttip != NULL) {
    ciKlass* k = ttip->klass();
@@ -920,6 +921,8 @@ const Type *PhiNode::Value( PhaseTransfo
    // into a Phi which "knows" it's an Interface type we'll have to
    // uplift the type.
    if( !t->empty() && ttip && ttip->is_loaded() && ttip->klass()->is_interface() )
+      { assert(ft == _type, ""); } // Uplift to interface
+    else if( !t->empty() && ttip && ttkp->klass()->is_loaded() && ttkp->klass()->is_interface() )
      { assert(ft == _type, ""); } // Uplift to interface
    // Otherwise it's something stupid like non-overlapping int ranges
    // found on dying counted loops.

As an aside, I ended up tracking this down by modifying PhaseIdealLoop so that I could use it as a graph verifier and then modified PhaseIterGVN to verify the graph after every transform.  This got me within 1 node of the bad transform.  Very handy.
                                     
2008-12-23
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/35ae4dd6c27c
                                     
2009-01-15
SUGGESTED FIX

Fix is available for inclusion into 6u11-rev-b06. Webrev available here:
http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=2789
                                     
2009-01-22



Hardware and Software, Engineered to Work Together