JDK-8221917 : serviceability/sa/TestPrintMdo.java fails on 32-bit platforms
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 11,12,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-04-03
  • Updated: 2019-09-26
  • Resolved: 2019-04-07
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 JDK 13
11.0.4Fixed 12.0.2Fixed 13 b16Fixed
Related Reports
Relates :  
JDK-8204240 - Extend MDO to allow more reasons to be recorded per bci
Relates :  
JDK-8215568 - Refactor SA clhsdb tests to use ClhsdbLauncher
Description
Fails like this on x86_32:

 stderr: [ MethodData 0xdf434618 for method sun/nio/fs/UnixPath.checkNotNul(Ljava/lang/String;C)V@0xdf4196f8
0 bci: 1 BranchData 	taken(0) displacement(412)
	not taken(32)
20 bci: 11 CounterData 	count(0)
--- Extra data:
40 bci: 0 ArgInfoData 	
MethodData 0xdf3bd5a0 for method jdk/internal/module/ModuleBootstrap$2.next()Ljava/lang/Object;@0xdf3bcd70
0 bci: 4 VirtualCallData 	Error: sun.jvm.hotspot.debugger.UnalignedAddressException: 36
]
 exitValue = -1

 LingeredApp stdout: [];
 LingeredApp stderr: []
 LingeredApp exitValue = 0
java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'ReceiverTypeData' missing from stdout/stderr 

	at TestPrintMdo.main(TestPrintMdo.java:72)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:835)
Caused by: java.lang.RuntimeException: 'ReceiverTypeData' missing from stdout/stderr 

	at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:270)
	at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:148)
	at ClhsdbLauncher.run(ClhsdbLauncher.java:196)
	at TestPrintMdo.main(TestPrintMdo.java:68)
Comments
Fix Request (11u, 12u) Backporting this patch fixes SA on x86_32. Patch applies cleanly to 11u and 12u. The automatic test does not fail, because test refactoring that exposes it is 13-only. Manual testing with "jhsdb clhsdb ... printmdo -a" was done on x86_32 binaries: fails like in description without the patch, passes fine with the patch. The risk is low, as it is only SA-specific fix for x86_32. Also passes all serviceability/sa tests.
09-04-2019
RFR: https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-April/037632.html
05-04-2019
JDK-8204240 is present since 11, so the bug is in 11, 12, 13, even though tests expose it only starting 13. Added proper affects-versions.
05-04-2019
SA and VM seem to disagree about the receiverOffset(0) value, with SA being 4 bytes (1 slot) smaller. I think this is due to JDK-8204240 that increased the header size to two slots on x86_32. Fix that works: diff -r 776b261dff84 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java Fri Apr 05 09:06:19 2019 +0200 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java Fri Apr 05 15:41:26 2019 +0200 @@ -170,11 +170,11 @@ } static int bciOffset() { return 2; } public static int cellOffset(int index) { - return MethodData.cellSize + index * MethodData.cellSize; + return headerSizeInBytes() + index * MethodData.cellSize; } // // Return a value which, when or-ed as a byte into _flags, sets the flag. // static int flagNumberToByteConstant(int flagNumber) { // assert(0 <= flagNumber && flagNumber < flagLimit, "oob"); // DataLayout temp; temp.setHeader(0);
05-04-2019
...which also makes no sense, because it goes against the C++ definition of ReceiverTypeData.
05-04-2019
Ha, I think non-JVMCI builds read receiver data at wrong offset. This helps to pass the TestPrintMdo test with x86_32: diff -r 776b261dff84 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java Fri Apr 05 09:06:19 2019 +0200 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ReceiverTypeData.java Fri Apr 05 13:26:39 2019 +0200 @@ -37,20 +37,19 @@ // dynamic type check. It consists of a counter which counts the total times // that the check is reached, and a series of (Klass, count) pairs // which are used to store a type profile for the receiver of the check. public class ReceiverTypeData<K,M> extends CounterData { static final int INCLUDE_JVMCI; - static final int nonProfiledCountOffset = counterCellCount; static final int receiver0Offset; static final int count0Offset; static final int receiverTypeRowCellCount; static { INCLUDE_JVMCI = VM.getVM().getTypeDataBase().lookupIntConstant("INCLUDE_JVMCI"); if (INCLUDE_JVMCI == 1) { - receiver0Offset = nonProfiledCountOffset + 1; + receiver0Offset = counterCellCount + 1; } else { - receiver0Offset = counterCellCount; + receiver0Offset = countOff; } count0Offset = receiver0Offset + 1; receiverTypeRowCellCount = (count0Offset + 1) - receiver0Offset; } final MethodDataInterface<K,M> methodData;
05-04-2019
Bisecting shows it happens in 13 after JDK-8215568, but it might just mean that test refactoring exposed the bug. It seems that one of the receivers in VirtualCallData is garbled. Supplying -XX:TypeProfileWidth=0 makes the test path. This might indicate the interpreter profiling trouble on x86_32.
03-04-2019