JDK-6689653 : JMapPerm fails with UseConcMarkSweepIncGC and compressed oops off
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 7
- Priority: P3
- Status: Closed
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2008-04-16
- Updated: 2013-03-04
- Resolved: 2011-03-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.
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 | JDK 7 | Other |
|---|---|---|
6u18Fixed  |
7 b47Fixed |
hs15Fixed |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
Even with compressed oops off, CMS thinks it's walking objects but it's really walking ChunkHeaders. The nsk test heapdump/JMapPerm crashes intermittently on linux-amd and solaris spacv9. (I don't know how compressed oops changes could have broken this but there were a lot so who knows?) machine: vm-v20z-25.sfbay dir: /net/sqenfs-2.sfbay/export2/results/vm/gtee/JDK7/ADHOC/VM/COOPs/2008-04-07-194235/CoopsOff_ConcMarkSweepIncGC/vm/linux-amd64/server/comp/vm-linux-amd64_server_comp_vm.heapdump.testlist2008-04-11-17-42-10 Platform Faulting addr (looks like a chunk header) is: siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000011;; Stack is: Instructions: (pc=0x00002aaaab5e2217) 0x00002aaaab5e2207: 9b 00 45 89 ea 4a 8d 14 d5 00 00 00 00 49 03 11 0x00002aaaab5e2217: 4c 8b 6a 10 48 8d 7a 10 41 ff 95 18 01 00 00 31 ;; Stack: [0x0000000040526000,0x0000000040627000], sp=0x0000000040625880, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x4c2217];; _ZN13DumperSupport16dump_field_valueEP10DumpWritercPh+0xa7 V [libjvm.so+0x4c37ce];; _ZN13DumperSupport20dump_instance_fieldsEP10DumpWriterP7oopDesc+0x42e V [libjvm.so+0x4c4422];; _ZN13DumperSupport13dump_instanceEP10DumpWriterP7oopDesc+0x132 V [libjvm.so+0x4c64ac];; _ZN16HeapObjectDumper9do_objectEP7oopDesc+0x29c V [libjvm.so+0x37ff5f];; _ZN24CompactibleFreeListSpace14object_iterateEP13ObjectClosure+0x8f V [libjvm.so+0x4a5447];; _ZN27GenerationObjIterateClosure8do_spaceEP5Space+0x17 V [libjvm.so+0x3b5f87];; _ZN29ConcurrentMarkSweepGeneration13space_iterateEP12SpaceClosureb+0x17 V [libjvm.so+0x4a3ade];; _ZN10Generation14object_iterateEP13ObjectClosure+0x2e V [libjvm.so+0x3be1d9];; _ZN29ConcurrentMarkSweepGeneration14object_iterateEP13ObjectClosure+0x69 V [libjvm.so+0x490e68];; _ZN16GenCollectedHeap14object_iterateEP13ObjectClosure+0x38 V [libjvm.so+0x4c72fc];; _ZN13VM_HeapDumper4doitEv+0x24c V [libjvm.so+0xa776a7];; _ZN12VM_Operation8evaluateEv+0x97 V [libjvm.so+0xa76616];; _ZN8VMThread18evaluate_operationEP12VM_Operation+0xc6 V [libjvm.so+0xa76a88];; _ZN8VMThread4loopEv+0x2a8 V [libjvm.so+0xa76273];; _ZN8VMThread3runEv+0xc3 V [libjvm.so+0x84cabd];; _Z10java_startP6Thread+0x16d hs_err log attached. Oh, I volunteer to try to fix this with bug 6687581.
Comments
|