JDK-6479208 : Regression: 4 tests are failing with 5.0u10 b01 while passing with 5.0u8b03
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 5.0u10
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2006-10-06
  • Updated: 2010-08-24
  • Resolved: 2006-10-12
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 Availabitlity Release.

To download the current JDK release, click here.
5.0u10 b02Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
The following tests:
nsk/sajdi/SACoreAttachingConnector/attach/attach001     execute_script
nsk/sajdi/SACoreAttachingConnector/attach/attach002     execute_script
nsk/sajdi/jdb/options/connect/connect002        execute_script
nsk/sajdi/jdb/options/connect/connect004        execute_script

fail with 5.0u10 b01 while they pass with with 5.0u8b03 (previous release FCS). They fail with -client only, with -server they pass for both builds. This is an obvious regression. VM SQE engineers confirmed that it shouldn't be a test issue.

SUGGESTED FIX (refer to $HS/src/share/vm/memory/filemap.hpp) as part of fix for 6323299 (Supply shared archive with alignment info). SA has this structure here $HS/agent/src/os/solaris/proc/saproc.cpp. In particular, the field size_t _alignment needs to be added to struct FileMapInfo in SA code. In addtion, there may be semantic changes due to the new alignment field (need to check that). Note: similar fix needs to be done in Linux SA native code as well (see $HS/agent/src/os/linux/ps_core.c - struct FileMapInfo - add size_t _alignment field there as well).

EVALUATION With class sharing enabled, classes.jsa file is mapped as MAP_SHARED segment(s?). These MAP_SHARED pages are not dumped into core. SA has a workaround to handle this case. SA gets the name of class sharing archive file from the core dump and "maps" in pages not found in core by reading classes.jsa. Towards this, SA has to know header format of shared archive file. Recently, there was a change in file header and so SA needs to be sync'ed. See "Suggested Fix" as well.

EVALUATION Shared mapping does not look right. Something wrong with classes.jsa file. libsaproc DEBUG: opened shared archive file /export/home/JDK/jdk1.5.0_10/jre/lib/sparc/client/classes.jsa libsaproc DEBUG: shared file offset 4194304 mapped at 0x2000, size = 8388608, read only? = 5402264 libsaproc DEBUG: shared file offset 0 mapped at 0x52a000, size = 12582912, read only? = 5664440 libsaproc DEBUG: shared file offset 0 mapped at 0xa92000, size = 4194304, read only? = 799404 libsaproc DEBUG: shared file offset 0 mapped at 0xb56000, size = 4194304, read only? = 19240

EVALUATION Cause of the problem is missing shared heap area in the core file. >>>libsaproc DEBUG: read failed at 0xd533c000, attempting shared heap area

WORK AROUND Use vm option "-XX:-UseSharedSpaces" for debuggee.

EVALUATION SA seems to work fine when shared spaces is turned off in debuggee.

SUGGESTED FIX I reproduced the UnmappedAddressException with jmap -histo [on Solaris/sparc]. Steps to reproduce * ran a simple infinite looping program * ran it with -Xshare:on -client option * created a core dump with gcore * ran jmap -histo against that core dump I got the following exception: Attaching to core core.23396 from executable ./java, please wait... Debugger attached successfully. Client compiler detected. JVM version is 1.5.0_10-b02 Iterating over heap. This may take a while... Unknown oop at 0xcd028de8 Oop's klass is null Object Histogram: Size Count Class description ------------------------------------------------------- 1548000 27537 * MethodKlass 1261552 2220 * ConstantPoolKlass 1010576 2220 * InstanceKlassKlass 907408 2220 * ConstantPoolCacheKlass 376472 2237 byte[] 253632 10568 Exception in thread "main" sun.jvm.hotspot.debugger.UnmappedAddressException at sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:191) at sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:46) at sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:188) at sun.jvm.hotspot.debugger.proc.ProcDebuggerLocal.readCInteger(ProcDebuggerLocal.java:312) at sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:425) at sun.jvm.hotspot.debugger.proc.ProcDebuggerLocal.readOopHandle(ProcDebuggerLocal.java:326) at sun.jvm.hotspot.debugger.proc.ProcAddress.getOopHandleAt(ProcAddress.java:96) at sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:198) at sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:330) at sun.jvm.hotspot.oops.OopField.getValue(OopField.java:27) at sun.jvm.hotspot.oops.Klass.getName(Klass.java:63) at sun.jvm.hotspot.oops.ObjectHistogramElement.getDescription(ObjectHistogramElement.java:60) at sun.jvm.hotspot.oops.ObjectHistogramElement.printOn(ObjectHistogramElement.java:96) at sun.jvm.hotspot.oops.ObjectHistogram.printOn(ObjectHistogram.java:50) at sun.jvm.hotspot.oops.ObjectHistogram.print(ObjectHistogram.java:43) at sun.jvm.hotspot.tools.ObjectHistogram.run(ObjectHistogram.java:27) at sun.jvm.hotspot.tools.JMap.run(JMap.java:85) at sun.jvm.hotspot.tools.Tool.start(Tool.java:204) at sun.jvm.hotspot.tools.JMap.main(JMap.java:126) Made the following change in $HS/agent/src/os/solaris/proc/saproc.cpp sccs diffs saproc.cpp ------- saproc.cpp ------- 349a350 > size_t _alignment; [adding one field in FileMapInfo struct definition]. I copied the newly built libsaproc.so under $JDK/jre/lib/sparc after renaming the original libsaproc.so jmap -histo works without exception and shows full histogram. The same change has to be done for Linux in the file $HS/agent/src/os/linux/ps_core.c as well. ------- ps_core.c ------- 207c207,208 < --- > size_t _alignment; > I've not tested the fix with jmap -histo on Linux.