JDK-6865265 : JVM crashes with "missing exception handler" error
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6u12
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2009-07-27
  • Updated: 2017-10-26
  • Resolved: 2012-01-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 7 JDK 8 Other
7-poolResolved 8Fixed hs23Fixed
Related Reports
Duplicate :  
JDK-8182272 - JVM crash with guarantee(false) failed: missing exception handler
Relates :  
JDK-7106907 - 64 bit VM fails test compiler/6865265/StackOverflowBug.java
Relates :  
JDK-8182272 - JVM crash with guarantee(false) failed: missing exception handler
Description
JVM core dumps with "missing exception handler"

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (sharedRuntime.cpp:461), pid=9246, tid=1887792016
#  Error: guarantee(false,"missing exception handler")
#
# Java VM: Java HotSpot(TM) Server VM (11.2-b01 mixed mode linux-x86)
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x70620800):  JavaThread "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon [_thread_in_vm, id=9393, sta
ck(0x70806000,0x70857000)]

Stack: [0x70806000,0x70857000],  sp=0x7080bc44,  free space=23k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x60671b]
V  [libjvm.so+0x2d395f]
V  [libjvm.so+0x564e2e]
V  [libjvm.so+0x55eda9]
V  [libjvm.so+0x55eff6]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~ExceptionBlob
J  oracle.mds.internal.cache.JOCCache.get(Ljava/lang/Object;)Ljava/lang/Object;
J  oracle.mds.internal.cache.LayeredCache.getCacheAccess(Ljava/lang/Object;)Ljava/lang/Object;
J  oracle.mds.core.MetadataObject.getBaseMOFromCache(Loracle/mds/internal/core/MDSContext;Loracle/mds/internal/cache/LayeredCache;Loracle/mds/internal/cache/
CacheKey;Loracle/mds/core/MOReference;)[Ljava/lang/Object;
j  oracle.mds.core.MetadataObject.getBaseMO(Loracle/mds/core/MDSInstance;Loracle/mds/internal/core/MDSContext;Loracle/mds/persistence/PManager;Loracle/mds/co
re/MOReference;)[Ljava/lang/Object;+77
J  oracle.mds.core.MDSSession.getBaseMO(Loracle/mds/core/MOReference;)[Ljava/lang/Object;
J  oracle.mds.core.MDSSession.getMetadataObject(Loracle/mds/core/MOReference;)Loracle/mds/core/MetadataObject;
J  oracle.jbo.mom.DefinitionManager.doFindSessionDefObject(ILjava/lang/String;Ljava/lang/String;ILjava/lang/Class;Z)Ljava/lang/Object;
j  oracle.jbo.mom.DefinitionManager.findPersDefObject(Ljava/lang/String;ILjava/lang/Class;Z)Ljava/lang/Object;+18
j  oracle.jbo.server.MetaObjectManager.findPersMetaObject(Ljava/lang/String;ILjava/lang/Class;Z)Ljava/lang/Object;+7
j  oracle.jbo.server.ComponentObjectImpl.applyPersonalization()V+24
j  oracle.jbo.server.ViewObjectImpl.applyPersonalization()V+1
j  oracle.jbo.server.ApplicationModuleImpl.callCreate(Loracle/jbo/server/ComponentObjectImpl;)V+35
j  oracle.jbo.server.ApplicationModuleImpl.doCreateViewObject(Ljava/lang/String;Loracle/jbo/server/ViewDefImpl;Z)Loracle/jbo/ViewObject;+133
j  oracle.jbo.server.ApplicationModuleImpl.createViewObject(Ljava/lang/String;Loracle/jbo/server/ViewDefImpl;)Loracle/jbo/ViewObject;+4
j  oracle.jbo.server.ViewObjectImpl.createViewLinkAccessorVO(Loracle/jbo/server/AssociationDefImpl;Ljava/lang/String;Loracle/jbo/server/ViewDefImpl;Loracle/j
bo/server/ViewLinkDefImpl;)Loracle/jbo/server/ViewObjectImpl;+6
j  oracle.jbo.server.AssociationDefImpl.createAccessorVO(Loracle/jbo/server/ViewDefImpl;Loracle/jbo/server/ViewLinkDefImpl;Loracle/jbo/server/EntityAssociati
on;Loracle/jbo/server/ViewObjectImpl;Loracle/jbo/server/ApplicationModuleImpl;Loracle/jbo/Row;Ljava/lang/String;Z)Loracle/jbo/server/ViewObjectImpl;+26
j  oracle.jbo.server.AssociationDefImpl.getAccessorVO(Loracle/jbo/Row;Loracle/jbo/server/ViewObjectImpl;Loracle/jbo/server/ViewDefImpl;Loracle/jbo/server/Vie
wLinkDefImpl;Loracle/jbo/server/EntityAssociation;Ljava/lang/String;Z)Loracle/jbo/ViewObject;+76
j  oracle.jbo.server.ViewAttributeDefImpl.getAccessorVO(Loracle/jbo/ViewObject;)Loracle/jbo/ViewObject;+101
j  oracle.jbo.ViewCriteriaItem.getAccessorVO(Loracle/jbo/ViewObject;)Loracle/jbo/ViewObject;+5
J  oracle.jbo.ViewCriteriaItem.copyFrom(Loracle/jbo/ViewCriteriaItem;)V
J  oracle.jbo.ViewCriteriaRow.copyFrom(Loracle/jbo/ViewCriteriaRow;)V
J  oracle.jbo.ViewCriteria.copyFrom(Loracle/jbo/ViewCriteria;)V
...
(The stack is about 4000 levels deep)

...


Environment Variables:
JAVA_HOME=/slot/ems3301/appmgr/view_storage/d7b7a_em_soa/jrockit_160_05_R27.6.2-20
CLASSPATH=/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/patch_wls1031/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/slot/ems
3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/patch_jdev1111/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/slot/ems3301/appmgr/view_s
torage/appmgr_D07B7A/fmwtools/mw_home/patch_cie680/profiles/default/sys_manifest_classpath/weblogic_patch.jar:/slot/ems3301/appmgr/view_storage/d7b7a_em_soa/
jrockit_160_05_R27.6.2-20/lib/tools.jar:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/utils/config/10.3.1.0/config-launch.jar:/slot/ems330
1/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/wlserver_10.3/server/lib/weblogic_sp.jar:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_hom
e/wlserver_10.3/server/lib/weblogic.jar:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/modules/features/weblogic.server.modules_10.3.1.0.ja
r:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/wlserver_10.3/server/lib/webservices.jar:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/f
mwtools/mw_home/modules/org.apache.ant_1.7.0/lib/ant-all.jar:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/modules/net.sf.antcontrib_1.0.0
.0_1-0b2/lib/ant-contrib.jar:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/Oracle_SOA1/modules/oracle.jrf_11.1.1/jrf.jar:/slot/ems3301/app
mgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/jdeveloper/webcenter/modules/oracle.portlet.server_11.1.1/oracle-portlet-api.jar::/slot/ems3301/appmgr/view_s
torage/appmgr_D07B7A/fmwtools/mw_home/wlserver_10.3/common/eval/pointbase/lib/pbclient57.jar:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home
/wlserver_10.3/server/lib/xqrl.jar
PATH=/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/wlserver_10.3/server/bin:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_ho
me/modules/org.apache.ant_1.7.0/bin:/slot/ems3301/appmgr/view_storage/d7b7a_em_soa/jrockit_160_05_R27.6.2-20/jre/bin:/slot/ems3301/appmgr/view_storage/d7b7a_
em_soa/jrockit_160_05_R27.6.2-20/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin
LD_LIBRARY_PATH=/slot/ems2708/appmgr/tool/jdk1.6.0_12/jre/lib/i386/server:/slot/ems2708/appmgr/tool/jdk1.6.0_12/jre/lib/i386:/slot/ems2708/appmgr/tool/jdk1.6
.0_12/jre/../lib/i386:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/wlserver_10.3/server/native/linux/i686::/slot/ems3301/appmgr/view_stor
age/appmgr_D07B7A/fmwtools/mw_home/wlserver_10.3/server/native/linux/i686:/slot/ems3301/appmgr/view_storage/appmgr_D07B7A/fmwtools/mw_home/wlserver_10.3/serv
er/native/linux/i686/oci920_8
SHELL=/bin/bash
DISPLAY=localhost:15.0

Signal Handlers:
SIGSEGV: [libjvm.so+0x6071f0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGBUS: [libjvm.so+0x6071f0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x5048b0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x5048b0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x5048b0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x5048b0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x506d80], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x506b20], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGTERM: [libjvm.so+0x506b20], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x506b20], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004


---------------  S Y S T E M  ---------------

OS:Enterprise Linux Enterprise Linux Server release 5.2 (Carthage)

uname:Linux 2.6.18-92.el5 #1 SMP Fri May 23 23:40:43 EDT 2008 x86_64
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 10240k, CORE infinity, NPROC 65535, NOFILE 65000, AS infinity
load average:0.86 0.98 0.98

CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 7 stepping 6, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3

Memory: 4k page, physical 32941100k(292456k free), swap 16474104k(16473676k free)

vm_info: Java HotSpot(TM) Server VM (11.2-b01) for linux-x86 JRE (1.6.0_12-ea-b03), built on Dec 22 2008 01:49:52 by "java_re" with gcc 3.2.1-7a (J2SE releas
e)

time: Thu Jul 23 11:09:53 2009
elapsed time: 11931 seconds
Comments
EVALUATION See main CR
28-10-2011
PUBLIC COMMENTS <###@###.###> wrote: There is a problem in the runtime exception handling code for C2-compiled methods with exception handler table entries which contain no entry with a '-1' handler_bci. Consider the following little run() method from the test program test/compiler/6865265/StackOverflowBug.java: public static int run() { try { try { return run(); } catch (Throwable e) { return 42; } } finally { } } javac compiles it to the following bytecode: public static int run(); Code: 0: invokestatic #2 // Method run:()I 3: istore_0 4: iload_0 5: ireturn 6: astore_0 7: bipush 42 9: istore_1 10: iload_1 11: ireturn 12: astore_2 13: aload_2 14: athrow Exception table: from to target type 0 4 6 Class java/lang/Throwable 0 4 12 any 6 10 12 any 12 13 12 any and the C2 JIT compiler creates the following compiled exception handler table for this method: ExceptionHandlerTable (size = 96 bytes) catch_pco = 20 (1 entries) bci -1 at scope depth 0 -> pco 32 catch_pco = 40 (2 entries) bci 6 at scope depth 0 -> pco 40 bci 12 at scope depth 0 -> pco 61 catch_pco = 72 (2 entries) bci 12 at scope depth 0 -> pco 72 bci 6 at scope depth 0 -> pco 85 Notice that the two table entries for the catch_pco 40 and 72 have no slot with a '-1' handler_bci. This leads to a problem in SharedRuntime::compute_compiled_exc_handler() if we try to find the right exception handler for the StackOverflowError exception which will eventually occur because of the unbound recursive call to run(). compute_compiled_exc_handler() computes the bci which corresponds to the native exception pc and calls methodOopDesc::fast_exception_handler_bci_for() with this bci and the corresponding exception class. fast_exception_handler_bci_for() then iterates over the methods exception table (the one from the class file shown above, not the compiled exception handler table) and tries to find the right exception handler bci for the actual exception class. During this search class loading or resolution may occur which can lead to a secondary exception being thrown. If that happens, fast_exception_handler_bci_for() will return the handler_bci which is currently under inspection together with a pending exception. If fast_exception_handler_bci_for() returns with a pending exception, compute_compiled_exc_handler() will reset handler_bci to -1 and will then try to find an entry in the compiled exception handler table for the current pco (i.e. the offset of the current native pc relative to the beginning of the method). But if the compiled exception handler table entry for that pco will have no -1 (i.e. 'catch_all') entry the lookup will fail badly and the VM will crash with a "missing exception handler" guarantee. Question: is it correct that we implicitly create 'catch_all' CatchProjNodes in Parse::catch_call_exceptions() with an handler_bci which is not '-1'? My fix retries the call to fast_exception_handler_bci_for() after it returned with a pending exception. It does this by supplying the handler_bci returned by that method as its new bci input parameter and it retries this as long as no new nested excepetion occurs. Notice that this will always be the case because every method has an artificial "catch all" exception handler which is able to catch all kind of exceptions so no nested exception can be thrown if fast_exception_handler_bci_for() will finally consider this exception handler. There's one additional thing we have to consider with this proposed change: compute_compiled_exc_handler() is called from OptoRuntime::handle_exception_C_helper() which caches the resulting compiled exception handler addresses together with the native exception pc in the corresponding nmethod. The next time an exception happens in the same nmethod at the same native pc, handle_exception_C_helper() immediately reuses the cached compiled exception handler addresses without calling compute_compiled_exc_handler() again. However, in the case where the first call to compute_compiled_exc_handler() resulted in the throwing of another nested exception, the returned exception handler pc isn't necessarily the right one for the new occurrence of this exception (because this time compute_compiled_exc_handler() could succeed without throwing another nested exception). So to cut a long story short, we shouldn't cache the exception handler pc computed by compute_compiled_exc_handler() if the handler is really for another (nested) exception than the original one.
06-10-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ec5ce9326985
05-10-2011
EVALUATION The root cause is infinite recursion in customer code. Keeping this bug open to evaluate the possibility of recognizing this scenario and providing a better diagnostic message.
12-09-2009