JDK-5024600 : nsk/jvmti/StopThread/stopthrd007 asserts on solx86
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: x86
  • Submitted: 2004-03-31
  • Updated: 2004-04-19
  • Resolved: 2004-04-08
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
5.0Resolved
Related Reports
Duplicate :  
JDK-4991286 - thread misses ThreadDeath of StopThread on Server VM
Relates :  
JDK-5010568 - Regression in 1.5.0 with -Xdebug flag on the modena test
Relates :  
JDK-5030853 - Lazy deopt and async exceptions cause deopt failures.
Description
The test is an testbase_nsk test:
    nsk/jvmti/StopThread/stopthrd007

This started occuring in tiger b42 and still fails in the c2 nightly test vm
on Mar. 30.

Note that when this bug is fixed, this stopthrd007 test will still fail
due to bug:
  4991286   thread misses ThreadDeath of StopThread on Server VM
    

The assertion is:
   ## Error: assert(SharedSkipVerify || obj->is_oop(),"sanity check")

The stack is:
V  [libjvm.so+0x83c5e0] ;; __1cHVMErrorOreport_and_die6M_v_+0x420
V  [libjvm.so+0x2b8dad] ;; __1cYreport_assertion_failure6Fpkci1_v_+0x4d
V  [libjvm.so+0x351b9c] ;; __1cKHandleAreaPallocate_handle6MpnHoopDesc__p2_+0xfc
V  [libjvm.so+0x8391f4] ;; __1cOcompiledVFrameScreate_stack_value6kMpnKScopeValue__pnKStackValue__+0x232
V  [libjvm.so+0x838676] ;; __1cOcompiledVFrameGlocals6kM_pnUStackValueCollection__+0x156
V  [libjvm.so+0x8367cb] ;; __1cSvframeArrayElementHfill_in6MpnOcompiledVFrame__v_+0x167
V  [libjvm.so+0x837b91] ;; __1cLvframeArrayHfill_in6MpnKJavaThread_ipnNGrowableArray4CpnOcompiledVFrame___pknLRegisterMap_i_v_+0x9e
V  [libjvm.so+0x837aa3] ;; __1cLvframeArrayIallocate6FpnKJavaThread_ipnNGrowableArray4CpnOcompiledVFrame___pnLRegisterMap_nFframe_9A9A9A_p0_+0x121
V  [libjvm.so+0x2c6916] ;; __1cODeoptimizationScreate_vframeArray6FpnKJavaThread_nFframe_pnLRegisterMap__pnLvframeArray__+0x476
V  [libjvm.so+0x2c5677] ;; __1cODeoptimizationYfetch_unroll_info_helper6FpnKJavaThread__pn0ALUnrollBlock__+0x1f7
V  [libjvm.so+0x2c541f] ;; __1cODeoptimizationRfetch_unroll_info6FpnKJavaThread__pn0ALUnrollBlock__+0xcf

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~DeoptimizationBlob
J  nsk.jvmti.StopThread.stopthrd007ThreadRunning.run()V
v  ~OSRAdapter
v  ~StubRoutines::call_stub
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-beta2
14-06-2004
EVALUATION ###@###.### 2004-04-02 I think, this bug has the same problem as 4991286 and 5010568. All of them are cause by the implementation of lazy deoptimization (build 20). John's putback (build 42) simply exposes the problem. It is C2/runtime issue so I will keep the bugs in C2 subcategory. We may consider it as showstoper for beta2. ###@###.### 2004-04-07 Ok. This bug is definitely the duplicate of 4991286 and 5023643. It give the assert now instead of loosing the exception due to different registers allocation since build 42. But even before b42 it was broken - we were lucky that the oop in the deoptimized code use the same register as the register we store a pending exception's oop in (see outputs in Comments). I am closing this bug as duplicate of 4991286.
11-06-2004