United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6865265 JVM crashes with "missing exception handler" error
JDK-6865265 : JVM crashes with "missing exception handler" error

Details
Type:
Bug
Submit Date:
2009-07-27
Status:
Closed
Updated Date:
2013-04-24
Project Name:
JDK
Resolved Date:
2012-01-23
Component:
hotspot
OS:
linux
Sub-Component:
compiler
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u12
Fixed Versions:
hs23 (b03)

Related Reports
Backport:
Backport:
Relates:

Sub Tasks

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

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.
                                     
2009-09-12
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ec5ce9326985
                                     
2011-10-05
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.
                                     
2011-10-06
EVALUATION

See main CR
                                     
2011-10-28



Hardware and Software, Engineered to Work Together