JDK-8171155 : Scanning method file for initialized final field updates can fail for non-existent fields
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 7,8,9
- Priority: P2
- Status: Resolved
- Resolution: Fixed
- Submitted: 2016-12-13
- Updated: 2017-11-29
- Resolved: 2016-12-19
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 7 | JDK 8 | JDK 9 |
|---|---|---|
| 7u171Fixed | 8Resolved  |
9 b151Fixed |
Related Reports
|
Relates :
|
Description
Scanning a method for initialized final field updates can fail (in Rewriter::scan_method()). If the field targeted by a putfield/putstatic is non-existent, klass->find_field() returns NULL and fd is not initialized. http://hg.openjdk.java.net/jdk9/hs/hotspot/file/a57e11acea79/src/share/vm/interpreter/rewriter.cpp#l429 However, as the return value of find_field() is not checked, data from the uninitialized field is read and that triggers an assert in set_has_initialized_final_field_update(). http://hg.openjdk.java.net/jdk9/hs/hotspot/file/a57e11acea79/src/share/vm/interpreter/rewriter.cpp#l433 # Internal Error (/opt/jprt/T/P1/120200.zmajo/s/hotspot/src/share/vm/runtime/handles.hpp:173), pid=8027, tid=0xe2eaeb40 # assert(_value != NULL) failed: resolving NULL _value [...] V [libjvm.so+0x9f021b] VMError::report_and_die()+0x17b V [libjvm.so+0x392638] report_vm_error(char const*, int, char const*, char const*)+0x68 V [libjvm.so+0x8cbaa7] fieldDescriptor::set_has_initialized_final_update(bool)+0x97 V [libjvm.so+0x8c9be6] Rewriter::scan_method(Method*, bool, bool*)+0xa76 V [libjvm.so+0x8c9d44] Rewriter::rewrite_bytecodes(Thread*)+0xb4 V [libjvm.so+0x8ca1cb] Rewriter::Rewriter(instanceKlassHandle, constantPoolHandle, Array<Method*>*, Thread*)+0x31b V [libjvm.so+0x8caef3] Rewriter::rewrite(instanceKlassHandle, Thread*)+0x123 V [libjvm.so+0x4d3c8e] InstanceKlass::rewrite_class(Thread*)+0x9e V [libjvm.so+0x4d528a] InstanceKlass::link_class_impl(instanceKlassHandle, bool, Thread*)+0x60a V [libjvm.so+0x4d550a] InstanceKlass::link_class(Thread*)+0x8a V [libjvm.so+0x4d554c] InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x1c V [libjvm.so+0x4d5b63] InstanceKlass::initialize(Thread*)+0x83 V [libjvm.so+0x62899d] find_class_from_class_loader(JNIEnv_*, Symbol*, unsigned char, Handle, Handle, unsigned char, Thread*)+0xed V [libjvm.so+0x649b67] JVM_FindClassFromCaller+0x4d7 C [libjava.so+0xa46d] Java_java_lang_Class_forName0+0x14d [...] This bug was triggered with the vm/classfmt/vrf/vrfpsf202/vrfpsf20202m1 test; the test tries to access a non-existent field and is expected to fail with: "Passed with runtime exception: java.lang.NoSuchFieldError: ibGlob" The bug triggered while I was testing the 8u backport of JDK-8157181 and JDK-8160551. The bug is not triggered with JDK 9, but it would be nevertheless good to fix it in 9 and then backport it to 8.
Comments
|