JDK-8243210 : ClhsdbScanOops fails with NullPointerException in FileMapHeader.inCopiedVtableSpace
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2020-04-21
  • Updated: 2023-08-08
  • Resolved: 2020-04-22
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 15
11.0.21Fixed 15 b20Fixed
Related Reports
Relates :  
JDK-8242787 - sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with sun.jvm.hotspot.types.WrongTypeException
Relates :  
JDK-8235220 - ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException
Relates :  
JDK-8241158 - SA TestHeapDumpForInvokeDynamic.java fails when CDS archive is relocated
Description
The following error happens in hs-tier2 testing. Seems to happen on OSX only.
...
0x00000007e4ba3b68 java/lang/String
0x00000007e4ba3bf8 java/lang/String
0x00000007e4ba3c88 java/lang/String
0x00000007e4ba3cc0 java/lang/String
0x00000007e4ba3e98 java/lang/String
Error: java.lang.NullPointerException
java.lang.NullPointerException
	at jdk.hotspot.agent/sun.jvm.hotspot.memory.FileMapInfo$FileMapHeader.inCopiedVtableSpace(FileMapInfo.java:154)
	at jdk.hotspot.agent/sun.jvm.hotspot.memory.FileMapInfo.inCopiedVtableSpace(FileMapInfo.java:134)
	at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:302)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102)
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:76)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.RobustOopDeterminator.oopLooksValid(RobustOopDeterminator.java:75)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$33.doit(CommandProcessor.java:1191)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2113)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2083)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1963)
	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:280)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:483)
hsdb> + quit
Comments
Fix Request: I would like this fixed in 11u since customers are hitting this problem. The fix is not clean: the surrounding code changed, and the ProblemList does not contain the lines the patch removes in the upstream version. However, the patch itself is really trivial and the risk is minimal. I tested this patch manually on Linux x64 and on arm32 with serviceability/sa/ClhsdbScanOops.java. In the GHAs, the crossbuilds are broken due to infrastructure problems; I manually tested the arm32 build. Patch RFR (reviewed by CL): https://git.openjdk.org/jdk11u-dev/pull/2066 Thanks, Thomas
07-08-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2066 Date: 2023-08-04 15:09:49 +0000
04-08-2023
URL: https://hg.openjdk.java.net/jdk/jdk/rev/46bca5e5e6fb User: cjplummer Date: 2020-04-22 22:11:08 +0000
22-04-2020
This is similar to the issues fixed by JDK-8235220 and JDK-8242787. While scanning the heap, SA goes too far (because it can't know the true top of the heap), and doesn't properly deal with reading in a garbage value. Although generally speaking SA is protecting against that, there are some sorts of failures where it doesn't not. In the other bugs it was not handling WrongTypeException, which can sometimes happen instead of an AddressException. In this particular bug SA is fetching a value of 0 out of the heap, creating an Address object out of it, and then trying to find out if that address if valid (call to RobustOopDeterminator.oopLooksValid()). Normally with a bad address the result would be an AddressException or WrongTypeException. However, "0" is special. When you try to create an Address object using 0 as the address, it returns null instead of an Address that maps to 0: /** From the BsdDebugger interface */ public BsdAddress readAddress(long address) throws UnmappedAddressException, UnalignedAddressException { long value = readAddressValue(address); return (value == 0 ? null : new BsdAddress(this, value)); } This null Address gets passed down to FileMapInfo$FileMapHeader.inCopiedVtableSpace() where it is finally dereferenced and results in an NPE. I looked around a bit and it appears that getting a null back when constructing an Address(0) is expected behavior, and the user of the the result needs to defend against it (my guess is there are other places that don't). In this case either FileMapInfo$FileMapHeader.inCopiedVtableSpace() or BasicTypeDataBase.findDynamicTypeForAddress() needs check for null first. I think the former is the better choice since it looks like there code in CommandProcessor.java for the clhsdb "inspect" command would otherwise also need this check.
21-04-2020