JDK-7144405 : JumbleGC002 assert(m->offset() == pc_offset) failed: oopmap not found
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_2.6
  • CPU: x86,ppc
  • Submitted: 2012-02-10
  • Updated: 2012-10-10
  • Resolved: 2012-03-24
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
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
Relates :  
Description
This appears to be a new failure in the nightlies.

http://sqeweb/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2012-02-08/Comp_Baseline/vm/windows-amd64/server/comp/windows-amd64_vm_server_comp_vm.gc.testlist/ResultDir/JumbleGC002/

;; Using jvm: "C:/local/common/jdk/baseline/windows-amd64/jre/bin/server/jvm.dll"

Warning: This error log is *not* generated by the following JVM:
           C:/local/common/jdk/baseline/windows-amd64/jre/bin/server/jvm.dll
         
         Expected vm_info: [Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-201202080913.rwestrel.hotspot-fastdebug) for windows-amd64 JRE (1.8.0), built on Feb  8 2012 01:20:42 by "jprtadm" with unknown MS VC++:1600]
         Actual vm_info:   []
         
         JVM symbol lookup may be incorrect.
         Please use --jvm=<path/to/jvm> to point to the correct JVM.
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (C:\temp\jprt\P1\091302.rwestrel\source\src\share\vm\compiler\oopMap.cpp:308), pid=11132, tid=3248
#  assert(m->offset() == pc_offset) failed: oopmap not found
#
# JRE version: 7.0_04-b10
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-201202080913.rwestrel.hotspot-fastdebug compiled mode windows-amd64 )
# Core dump written. Default location: c:\local\58069.JDK7.NIGHTLY.VM_windows-amd64_vm_server_comp_vm.gc.testlist\results\ResultDir\JumbleGC002\hs_err_pid11132.mdmp
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

VM Arguments:
jvm_args: -Xcomp -XX:-PrintVMOptions -XX:CompileThreshold=100 -XX:DefaultMaxRAMFraction=8 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:-UseGCOverheadLimit 
java_command: gc.gctests.JumbleGC002.JumbleGC002 -stressTime 30
Launcher Type: SUN_STANDARD



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

OS: Windows Server 2008 , 64 bit Build 6002 Service Pack 2

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

Memory: 4k page, physical 4192984k(1797624k free), swap 8608488k(6816536k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (23.0-b15-internal-201202080913.rwestrel.hotspot-fastdebug) for windows-amd64 JRE (1.8.0), built on Feb  8 2012 01:20:42 by "jprtadm" with unknown MS VC++:1600

time: Thu Feb 09 13:44:17 2012
elapsed time: 21 seconds

# Host info: CYGWIN_NT-6.0-WOW64 jfx-vm444-new 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b522995d91f0
22-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/b522995d91f0
18-02-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b522995d91f0
14-02-2012

EVALUATION The change in 7119286 is incomplete. In StubGenerator::generate_throw_exception() it stores a pc that is not the pc at the call to the thread last frame anchor but it doesn't use this pc in the oopmap.
13-02-2012

EVALUATION This appears to have been caused by the 7144405 changes. It started crashing with this push. I suspect that the alignment logic is unsafe in some unusual context where the StackOverflowError is thrown.
11-02-2012