JDK-8047383 : SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-06-19
  • Updated: 2017-07-26
  • Resolved: 2014-10-23
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.
JDK 8 JDK 9
8u40Fixed 9 b40Fixed
Related Reports
Duplicate :  
JDK-8054083 - SIGSEGV with bigapps/Weblogic+medrec in C2 method
Duplicate :  
JDK-8044729 - Intermittent SIGBUS on SPECjbb2013-CMS on Solaris SPARC with 9-b12
Relates :  
JDK-8068881 - SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.
Description
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0xffffffff6a9728b4, pid=26788, tid=26
#
# JRE version: Java(TM) SE Runtime Environment (9.0-b18) (build 1.9.0-ea-fastdebug-b18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-201406162333.iggy.8046769-fastdebug compiled mode solaris-sparc )
# Problematic frame:
# J 95456 C2 weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.<init>(Lweblogic/wsee/jaxws/framework/jaxrpc/EnvironmentFactory;Lcom/sun/xml/ws/api/model/wsdl/WSDLModel;)V (313 bytes) @ 0xffffffff6a9728b4 [0xffffffff6a971c00+0xcb4]
#

Unfortunately the hs_err file is not complete but the core file seems to be there.
Comments
verified by nightly testing
26-07-2017
Tested with > 50 of iterations of SPECjbb2013, where we also hit this problem. Everything seems ok. Performance-wise there is no measurable difference, which is not surprising since matcher will aggressively clone constants (and constant table loads).
21-10-2014
Here is what I think the problem is (with some probability...): diff --git a/src/share/vm/opto/coalesce.cpp b/src/share/vm/opto/coalesce.cpp --- a/src/share/vm/opto/coalesce.cpp +++ b/src/share/vm/opto/coalesce.cpp @@ -281,9 +281,12 @@ Block *pred = _phc._cfg.get_block_for_node(b->pred(j)); Node *copy; assert(!m->is_Con() || m->is_Mach(), "all Con must be Mach"); - // Rematerialize constants instead of copying them - if( m->is_Mach() && m->as_Mach()->is_Con() && - m->as_Mach()->rematerialize() ) { + // Rematerialize constants instead of copying them. + // We do this only for immediate constants, we avoid constant table loads + // because that will unsafely extend the live range of the constant table base. + // We will however clone constant table loads in PhaseChaitin::split_Rematerialize(). + if( m->is_Mach() && m->as_Mach()->is_Con() && !m->as_Mach()->is_MachConstant() && + m->as_Mach()->rematerialize()) { copy = m->clone(); // Insert the copy in the predecessor basic block pred->add_inst(copy); @@ -317,7 +320,7 @@ assert(!m->is_Con() || m->is_Mach(), "all Con must be Mach"); // At this point it is unsafe to extend live ranges (6550579). // Rematerialize only constants as we do for Phi above. - if(m->is_Mach() && m->as_Mach()->is_Con() && + if(m->is_Mach() && m->as_Mach()->is_Con() && !m->as_Mach()->is_MachConstant() && m->as_Mach()->rematerialize()) { copy = m->clone(); // Insert the copy in the basic block, just before us We're rematerializing constant table loads (which are is_Con()) and are stretching the lrg of the constant table base. If that lrg is a multidef (it gets spilled into different registers and then merged) then I think we're in trouble. On one hand the fix will stretch lrgs on constants instead of reloading them, on the other hand if there is pressure we're going to split them (in split_Rematerialize()) and in that case rematerialization is going to happen just fine. To confirm that thought I ran benchmarks and there is no difference at all. Running stability tests now (SPECjbb2013 on a T4 in loop), that will take some time since I don't have a real test case.
17-10-2014
So, I was wrong before and it is a register allocation problem. It seems that the problem was introduced by the fix for JDK-8022783. When we're rematerializing a load from the constant table something wrong happens with it's input (which is the constant table base). I don't see anything particularly wrong with the fix for JDK-8022783 so far though.
09-10-2014
Same story as before it seems, register allocation seems fine. Seems like a stack stomp of some kind...
22-07-2014
Seems to be the same problem
21-07-2014
This is likely a dup of JDK-8044729. The crash is during the constant table load. The constant table base has a bogus value.
21-07-2014
ILW=weblogic crash;solaris-sparc only, not very often;none=HLH=>P2
21-07-2014