JDK-8256746 : gc/CriticalNativeArgs.java fails without -XX:-CriticalJNINatives
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 8,11,15,16
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2020-11-20
- Updated: 2022-10-13
- Resolved: 2020-11-23
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.
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 16 |
|---|
16 b26Fixed  |
Related Reports
|
Relates :
|
Description
Found this with Zero testing, but the failure is not Zero-specific. It affects platforms that do not have CriticalJNINatives enabled. The issue is that the fallback (non-critical) version of the code calls GetArrayLength on known NULL array. $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/CriticalNativeArgs.java # # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/jniHandles.inline.hpp:91), pid=1909139, tid=1909217 # assert(handle != __null) failed: JNI handle should not be null It was exposed by JDK-8233343 that added the generic test configuration. Before that, the test was only enabled for specific GCs and arches where CriticalJNINatives are known to work.
Comments
|