Bug ID: JDK-8200613 SA: jstack throws UnmappedAddressException with a CDS core file

JDK-8200613 : SA: jstack throws UnmappedAddressException with a CDS core file

Type: Bug
Component: hotspot
Sub-Component: svc-agent
Affected Version: 10

Priority: P3
Status: Resolved
Resolution: Fixed
OS: linux
CPU: generic

Submitted: 2018-04-03
Updated: 2019-10-08
Resolved: 2018-12-12

Versions (Unresolved/Resolved/Fixed)

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 11	JDK 12
11.0.4Fixed	12 b24Fixed

Related Reports

CSR :	JDK-8214841 - Introduce a Hotspot option DumpPrivateMappingsInCore to determine if file-backed private mappings of the process can be dumped into the core file
Duplicate :	JDK-8200162 - Use coredump_filter to dump the MAP_SHARED regions of a CDS archive into a corefile
Duplicate :	JDK-8046560 - UnmappedAddressException while attaching to process or core when CDS is used
Relates :	JDK-8215026 - Incorrect amount of memory unmapped with ImageFileReader::close()
Relates :	JDK-8215342 - [Zero] Build fails after JDK-8200613
Relates :	JDK-8200162 - Use coredump_filter to dump the MAP_SHARED regions of a CDS archive into a corefile
Relates :	JDK-8215027 - Unmap the NIO file mappings with MapMode.PRIVATE on Linux before dumping a corefile.
Relates :	JDK-8215351 - Zero and Minimal VMs fail to build after JDK-8200613

Description

A 'jstack -v' on a corefile obtained from an Xshare:on process results in an UnmappedAddressException

[ jini-VirtualBox ClhsdbCDSCore ] $ sudo /home/jini/new16/hs/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/jhsdb clhsdb --core cds_core_file --exe /home/jini/new16/hs/build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java
Opening core file, please wait...
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not a function in sa.js at line number 54
Warning! JS Engine can't start, some commands will not be available.
hsdb> jstack -v 
Deadlock Detection:

No deadlocks found.

"Error accessing address 0x7bff58520
sun.jvm.hotspot.debugger.UnmappedAddressException: 7bff58520
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.checkPage(PageCache.java:208)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.PageCache.getData(PageCache.java:63)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readBytes(DebuggerBase.java:225)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCInteger(LinuxDebuggerLocal.java:494)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCompKlassAddressValue(DebuggerBase.java:477)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readCompKlassAddress(LinuxDebuggerLocal.java:440)
        at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxAddress.getCompKlassAddressAt(LinuxAddress.java:84)
        at jdk.hotspot.agent/sun.jvm.hotspot.oops.Oop.getKlassForOopHandle(Oop.java:210)
        at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:252)
        at jdk.hotspot.agent/sun.jvm.hotspot.oops.NarrowOopField.getValue(NarrowOopField.java:44)
        at jdk.hotspot.agent/sun.jvm.hotspot.oops.OopUtilities.threadOopGetName(OopUtilities.java:263)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.getThreadName(JavaThread.java:372)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaThread.printThreadInfoOn(JavaThread.java:485)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:77)
        at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1075)
        at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1983)
        at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1953)
        at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1833)
        at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
        at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439)
hsdb>

Comments

Fix Request for 11u: I want to backport changes in below: - JDK-8200613 - JDK-8215342 - JDK-8219414 - JDK-8219574 - JDK-8215026 They are very helpful for crash analysis. We can apply them straightly to 11u, but they need to apply them in same time. Risk is low because these changes affects only to coredump on Linux. They are covered with serviceability/sa tests.
13-05-2019
Withdrawing the corresponding CSR since the new option DumpPrivateMappingsInCore has been changed to a diagnostic option.
12-12-2018
[~mseledtsov] The option is proposed to be introduced due to concerns on the increase in the corefile size on Linux. More details in the mails: http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/025820.html
10-12-2018
Question: Why do we need an option? Why not always dump the image file into the core dump? Does it really add significant space to core file (as a relative percentage) ? This is the way it works on Solaris and OSX.
07-12-2018
As per the review comments, adding an option DumpPrivateMappingsInCore (true by default) to control the dumping of the file backed private mappings into the corefile for Linux. Also adding code to close the image file which contributes to about 140 MB. Currently there is a corelibs bug though (https://bugs.openjdk.java.net/browse/JDK-8215026) which causes the closure of the image file to not unmap the entire file.
07-12-2018
This issue is seen only when the CDS heap data relocation delta is 0 bytes. Typically not seeing this issue when the CDS heap data needs to be relocated.
07-12-2018
Review thread: http://openjdk.5641.n7.nabble.com/RFR-S-JDK-8200613-SA-jstack-throws-UnmappedAddressException-with-a-CDS-core-file-td352681.html#a354088
06-12-2018
Seen only on Linux with G1GC. Observed while trying to read in data from the shared strings region (the closed archive heap space) with G1GC. This region is not dumped into the corefile for Linux. This, being a heap region (and therefore being a read-write region) is also not read in from the classes.jsa file in SA since only the read only regions are read in while processing the core file. (The expectation being that the read write regions are in the core file). The closed archive heap space is getting dumped into the corefile with Solaris and OSX. Getting the corefile created after having the corresponding coredump_filter file to include bit 2 (file-backed private memory) (e.g., coredump filter value 0x37 as against 0x33) is one way to solve the issue.
24-09-2018