JDK-6788347 : C2Compiler crash 6u7
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0u17,6u7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: generic
  • Submitted: 2008-12-23
  • Updated: 2011-02-16
  • Resolved: 2009-01-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6 JDK 7 Other
5.0u18-rev,hs11.1Fixed 5.0u19Fixed 6u11-rev b07Fixed 7Fixed hs11.1Fixed
Related Reports
Relates :  
JDK-6952530 - C2 crash due to SIGSEGV in PhaseIdealLoop::build_loop_late_post()
Relates :  
JDK-6922056 - C2Compiler crash 6.0 u17
Relates :  
JDK-6847791 - crash in std_verified_entry
Relates :  
JDK-6891431 - crash in JDK 6u16 in build_loop_late_post
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 Fix is available for inclusion into 6u11-rev-b06. Webrev available here: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=2789
22-01-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/35ae4dd6c27c
15-01-2009
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.
23-12-2008