JDK-6891532 : 6u16 JVM crash when using -XX:+AggressiveOpts on 64-bit intel system
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u16
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2009-10-14
  • Updated: 2011-02-16
  • Resolved: 2009-11-06
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 6
6-poolResolved
Related Reports
Duplicate :  
JDK-6811384 - MacroAssembler::serialize_memory may touch next page on amd64
Description
Customer migrated their application from T2000 to Intel Xeon system running Solaris 10.  They started experiencing frequent crashes in production.

Stack seen from hs_err log:

Stack: [0xfffffd7f3f51b000,0xfffffd7f3f61b000],  sp=0xfffffd7f3f61a680,  free sp
ace=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J  java.lang.Thread.currentThread()Ljava/lang/Thread;
j  com.sun.ejb.containers.util.pool.NonBlockingPool.doResize()V+0
j  com.sun.ejb.containers.util.pool.NonBlockingPool$ReSizeWork.run()V+4
j  com.sun.ejb.containers.util.pool.NonBlockingPool$ReSizeWork.service()V+1
j  com.sun.ejb.containers.util.WorkAdapter.doWork()V+11

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  java.lang.Thread.currentThread()Ljava/lang/Thread;
j  com.sun.ejb.containers.util.pool.NonBlockingPool.doResize()V+0
j  com.sun.ejb.containers.util.pool.NonBlockingPool$ReSizeWork.run()V+4
j  com.sun.ejb.containers.util.pool.NonBlockingPool$ReSizeWork.service()V+1
j  com.sun.ejb.containers.util.WorkAdapter.doWork()V+11
J  com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run()V
v  ~StubRoutines::call_stub

The full hs_err log is attached.

We're having some troubles reading the core file even though there seem to be no mismatched libraries and the core file doesn't appear to be truncated.  The stack for
this thread from pstack is:

-----------------  lwp# 5168 / thread# 5168  --------------------
 fffffd7fff2cc99a _lwp_kill () + a
 fffffd7fff271c89 raise () + 19
 fffffd7fff251210 abort () + 90
 fffffd7ffed6e284 __1cCosFabort6Fb_v_ () + 44
 fffffd7ffee861b8 __1cHVMErrorOreport_and_die6M_v_ () + 948
 fffffd7ffe7a4efe JVM_handle_solaris_signal () + 7ae
 fffffd7ffe7a506e signalHandler () + e
 fffffd7fff2c7176 __sighndlr () + 6
 fffffd7fff2bba72 call_user_handler () + 252
 fffffd7fff2bbc8e sigacthandler (b, fffffd7f3f61a500, fffffd7f3f61a1a0) + de
 --- called from signal handler with signal 11 (SIGSEGV) ---
 fffffd7ffb158ded ???????? () + fffffffffbda84cd
 fffffd7ffb0058c9 * com/sun/ejb/containers/util/pool/NonBlockingPool.doResize()V
+0
 fffffd7ffb005a22 * com/sun/ejb/containers/util/pool/NonBlockingPool$ReSizeWork.
run()V+4 (line 1156)
 fffffd7ffb005a22 * com/sun/ejb/containers/util/pool/NonBlockingPool$ReSizeWork.
service()V+1 (line 1140)
 fffffd7ffb005efc * com/sun/ejb/containers/util/WorkAdapter.doWork()V+11 (line 1
49)
 fffffd7ffc3a2618 * *com/sun/corba/ee/impl/orbutil/threadpool/ThreadPoolImpl$Wor
kerThread.run()V [compiled] +101 (line 1128)

Please see Comments for pointer to the actual core file.
Comments
EVALUATION Closed as duplicate of 6811384. IDR fixed the issue, escalation closed by Cu. Integration into 6u17 will be done through 6811384.
06-11-2009
EVALUATION FVB was sent on Oct 20, 2009. (IDRJDK-6891532-20109114818.zip)
20-10-2009
WORK AROUND -XX:+UseMembar will use a membar instruction instead of the serialize page.
20-10-2009
EVALUATION This is a duplicate of 6811384.
20-10-2009
EVALUATION Just after thread is moved into native transition state, that occurs when a thread returns from a JNI call in SharedRuntime::generate_native_wrapper(), we write serialization page so VM thread can do a pseudo remote membar. We use the current thread pointer to calculate a thread specific offset to write to within the page, and calculation is wrong for 64 bit architectures (MacroAssembler::serialize_memory in hotspot/src/cpu/x86/vm/assembler_x86_64.cpp).
20-10-2009
WORK AROUND Removing -XX:+AggressiveOpts seems to lower the frequency of these crashes.
14-10-2009