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.
7u171Fixed 8Resolved 9 b151Fixed
Related Reports
Relates :  
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.


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().


#  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.
This bug is in the interpreter's bytecode rewriter and happens at class link time. Moving from hotspot/compiler -> hotspot/runtime for more visibility by the Runtime team.

Here is the webrev: http://cr.openjdk.java.net/~zmajo/8171155/webrev.00/ JPRT testing is in progress.