United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6479208 : Regression: 4 tests are failing with 5.0u10 b01 while passing with 5.0u8b03

Details
Type:
Bug
Submit Date:
2006-10-06
Status:
Resolved
Updated Date:
2010-08-24
Project Name:
JDK
Resolved Date:
2006-10-12
Component:
core-svc
OS:
solaris_10
Sub-Component:
tools
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u10
Fixed Versions:
5.0u10 (b02)

Related Reports
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
WORK AROUND

Use vm option "-XX:-UseSharedSpaces" for debuggee.
                                     
2006-10-10
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.
                                     
2006-10-10
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.
                                     
2006-10-10
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).
                                     
2006-10-10
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
                                     
2006-10-10
EVALUATION

Cause of the problem is missing shared heap area in the core file. 

>>>libsaproc DEBUG: read failed at 0xd533c000, attempting shared heap area
                                     
2006-10-10
EVALUATION

SA seems to work fine when shared spaces is turned off in debuggee.
                                     
2006-10-10



Hardware and Software, Engineered to Work Together