JDK-6550161 : VM crash during intensive class loading
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u2
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2007-04-25
  • Updated: 2012-02-01
  • Resolved: 2010-10-15
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
7Resolved
Related Reports
Duplicate :  
JDK-6852873 - Increase in delta between application stopped time and ParNew GC time over application lifetime
Relates :  
JDK-6654392 - Crash seen with jdk 1.6u1 with Internal Error 53594E4348524F4E495A45520E43505005B8
Description
The following test intermittently crashes VM: 
	runtime/ParallelClassLoading/stress/freeLock/reflect/inner-complex

Sometimes, in spite of a crash, the test hangs.
This behavior is observed on the host "dip.sfbay.sun.com".

hs_err files are attached.

Scripts for reproduction and execution results can be found here:
/net/gtee.sfbay/export/gtee/results/MUSTANG_UR/PROMOTION/VM-WEEKLY/1.6.0_02-ea-b02-070418171641/vm/RHAT4.0AS/client/batch/vm-vm_6.0_client_batch_RHAT4.0AS2007-04-18-17-21-38/ResultDir/inner-complex
We could see it for es and fr so far.
Is it possible to try with fastdebug with -XX:+CheckUnhandledOops?
Or with -XX:+VerifyBeforeGC -XX:+VerifyAfterGC?
Unfortunately, I can't reproduce this crash with a fastdebug VM (so far, 25 hours of continuous run without failure and it is still running). If I achieve a success, I'll try to reproduce it with the flags you suggested.
Comments
EVALUATION As part of the fix for 6852873, thanks to Dave Dice, we increased the scope of holding the ListLock in deflate_idle_monitors so we don't have more than one thread modifying monitor lists simultaneously.
15-10-2010
EVALUATION The crash looks like we've picked up a bad oop from the heap.
25-04-2007