JDK-6904403 : assert(f == k->has_finalizer(),"inconsistent has_finalizer") with debug VM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6u18,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-11-24
  • Updated: 2015-12-12
  • Resolved: 2014-05-28
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 6 JDK 7 JDK 8 JDK 9
6u105Fixed 7u91Fixed 8u66Fixed 9 b19Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
Fastdebug VM crashes with assertion:

#  Internal Error (/BUILD_AREA/jdk6_05/hotspot/src/share/vm/classfile/classFileParser.cpp:3198), pid=11743, tid=2
#  Error: assert(f == k->has_finalizer(),"inconsistent has_finalizer")
#
# Java VM: Java HotSpot(TM) Tiered VM (1.6.0_05-ea-fastdebug-b02-fastdebug mixed mode solaris-sparc)
# An error report file with more information is saved as:
# /net/sqenfs-1.sfbay/export1/comp/vm/gtee.dev/bin/jcov/hs_err_pid11743.log

Stack trace:
 ff2caa58 _lwp_kill (6, 0, ff342f98, ff2aa378, ffffffff, 6) + 8
 ff24194c abort    (fcd7ca88, 1, fdedefe4, fcb78, ff3413d8, 0) + 110
 fdecebe0 void os::abort(bool) (1, ffcc8344, ff011330, fec65b84, fefeec94, ff011330) + 168
 fe266774 void VMError::report_and_die() (8c400, ff011330, ff011330, ff0243f8, 1, 6) + e28
 fd671c94 void report_assertion_failure(const char*,int,const char*) (fe69615e, c7e, fe6961a5, 51053, fef9d840, 51000) + 68
 fd569bfc void ClassFileParser::set_precomputed_flags(instanceKlassHandle) (fcd7db84, fcd7d20c, d64db450, d6003900, 1, fef9d840) + 548
 fd562df8 instanceKlassHandle ClassFileParser::parseClassFile(symbolHandle,Handle,Handle,symbolHandle&,Thread*) (e4e28, 0, fcd7d204, fcd7d208, d64db458, d64db450) + a0f0
 fe0cd064 klassOop SystemDictionary::parse_stream(symbolHandle,Handle,Handle,ClassFileStream*,Thread*) (fcd7de50, fcd7de4c, fcd7de48, fcd7de44, fcd7de74, 34800) + 54
 fdca00f8 jvmtiError VM_RedefineClasses::load_new_class_versions(Thread*) (fcd7e0a0, 15fff8, 34800, 0, 0, 34804) + e98
 fdc95b68 bool VM_RedefineClasses::doit_prologue() (fcd7e0a0, 725d8, fcd, 72400, fef9d840, 3c) + 1a0
 fe293260 void VMThread::execute(VM_Operation*) (fcd7e0a0, 34800, fd607f70, fef9d840, fcdc0200, fff963ee) + fc
 fdc26938 jvmtiError JvmtiEnv::RetransformClasses(int,_jclass*const*) (9553c8, 16, d6204040, 34f78, 51400, fefeece0) + 1abc
 fdaf3460 jvmti_RetransformClasses (2c634, 16, 955370, 34800, 71ee, 71ee) + b28
 fcce4690 retransformClasses (34910, 10c00, fcd7e4d8, 435, 2c634, fccf84c0) + 218
 fcce164c Java_sun_instrument_InstrumentationImpl_retransformClasses0 (34910, fcd7e4e4, 0, 30128, fcd7e4d8, 0) + c
 fa8156f0 * sun/instrument/InstrumentationImpl.$$generated$$_retransformClasses0(J[Ljava/lang/Class;)V+6800
 fa8155b0 * sun/instrument/InstrumentationImpl.$$generated$$_retransformClasses0(J[Ljava/lang/Class;)V+0
 fa805a30 * sun/instrument/InstrumentationImpl.retransformClasses0(J[Ljava/lang/Class;)V+9
 fa805a30 * sun/instrument/InstrumentationImpl.retransformClasses([Ljava/lang/Class;)V+41 (line 241)
 fa805f50 * com/sun/tdk/jcov/Agent.premainV50(Ljava/lang/String;Ljava/lang/instrument/Instrumentation;)V+554 (line 404)
 fa805a30 * com/sun/tdk/jcov/Agent.premain(Ljava/lang/String;Ljava/lang/instrument/Instrumentation;)V+11 (line 295)
 fa8002d0 * StubRoutines (1)
 fd84624c void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (d61b1678, fcd7ea08, d61b1678, 34800, 0, fa800240) + 9d0
 fdfc9e60 oop Reflection::invoke(instanceKlassHandle,methodHandle,Handle,bool,objArrayHandle,BasicType,objArrayHandle,bool,Thread*) (fcd7f06c, fed25e58, 2, 34804, 0, 0) + 4790
 fdfdbf3c oop Reflection::invoke_method(oop,Handle,objArrayHandle,Thread*) (fcd7f06c, e4d98, fcd7f064, fcd7f060, 34800, e4d90) + df8
 fda7458c JVM_InvokeMethod (34910, 34800, fdeac674, 34800, 34800, 1) + d2c
 fcb14df8 Java_sun_reflect_NativeMethodAccessorImpl_invoke0 (34910, fcd7f210, fcd7f29c, 0, fcd7f294, 0) + 10
 fa8156f0 * sun/reflect/NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+-28704
 fa8155b0 * sun/reflect/NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0
 fa8058c0 * sun/reflect/NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+87 (line 55)
 fa8058c0 * sun/reflect/DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 (line 50)
 fa805de0 * java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+161 (line 1172)
 fa8058c0 * sun/instrument/InstrumentationImpl.loadClassAndStartAgent(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V+115 (line 631)
 fa805a30 * sun/instrument/InstrumentationImpl.loadClassAndCallPremain(Ljava/lang/String;Ljava/lang/String;)V+5 (line 676)
 fa8002d0 * StubRoutines (1)
 fd84624c void JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*) (d61acf08, fcd7f980, d61acf08, 34800, 0, fa800240) + 9d0
 fd893464 void jni_invoke_nonstatic(JNIEnv_*,JavaValue*,_jobject*,JNICallType,_jmethodID*,JNI_ArgumentPusher*,Thread*) (34910, fcd7f978, fefeece0, e, 51400, fcd7f958) + 18c8
 fd8b4e14 jni_CallVoidMethod (34910, ee790, ee874, 34800, 34800, fefeece0) + ad8
 fcce3634 invokeJavaAgentMainMethod (34910, ee790, ee874, 12f430, 12f434, 10800) + 64
 fcce303c startJavaAgent (30128, 34910, 30c00, 2c770, ee874, 1) + 3c
 fcce2fd8 processJavaStart (30128, 34910, fffef368, 1, fccf84c0, 10c00) + d8
 fcce20c8 eventHandlerVMInit (3012c, 34910, 12f41c, 16434, fccf84c0, e4720) + 40
 fdc4e118 void JvmtiExport::post_vm_initialized() (2fa38, fcce2088, 12f41c, 0, ead0, feffe4bc) + cd4
 fe128218 int Threads::create_vm(JavaVMInitArgs*,bool*) (34800, fefef00d, fefef00e, 0, 68c00, fef9d840) + 10cc
 fd947d7c JNI_CreateJavaVM (fcd7ff94, fcd7ff90, fcd7ff20, fe93fa06, 5e000, 0) + d8
 00013674 InitializeJVM (fcd7ff94, fcd7ff90, fcd7ff98, 42e, 2948c, 28b2c) + 12c
 000119d0 JavaMain (0, fcd80000, 0, 0, 28f5a, 1) + 90
 ff2c6d4c _lwp_start (0, 0, 0, 0, 0, 0)

Comments
SQE is ok to take the fix in PSU15_04.
27-08-2015

Adding critical watch since the jdk7/6 backports are related to JDK-8076110, and should be fixed at the same time if possible.
20-08-2015

I disagree that this issue appears only on artificial testcases. I hit it while trying to gather code coverage using jcov in dynamic instrumentation mode. Code coverage tools shouldn't care about such limitations on VM implementation. Hotspot can support or ignore redefinition of finalize(), but it should not issue any error. Otherwise, it's a specification violation.
02-04-2014

This issues appears on artificial testcase only.
17-10-2012

Artificial testcase redefine empty Object::finalize() to non-empty one. Despite the fact that spec doesn't limit methods that can be redefined, hotspot doesn't support this kind of redefinition.
17-10-2012

PUBLIC COMMENTS <deleted>
22-03-2012

EVALUATION in ClassFileParser::set_precomputed_flags() we check nearest super only when setting has_finalizer flag, but under assert we check all supers up to the java.lang.Object. So if we inject finalizer somewhere in the hierarchy it cause the difference between results of these two computations and assert will fail.
21-03-2012

EVALUATION I think the problem is that a klass is being changed from not having a finalizer to having one and that's really not going to work. Existing objects haven't been registered for finalization so their finalizer will never be called. I suspect this case should be rejected. Any change in finalizable should be rejected.
08-12-2009