JDK-8016619 : JRE crash
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 7u40
  • Priority: P2
  • Status: Closed
  • Resolution: Incomplete
  • OS: linux
  • CPU: x86
  • Submitted: 2013-06-14
  • Updated: 2014-01-29
  • Resolved: 2014-01-29
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 7
7u60Resolved
Related Reports
Relates :  
JDK-6904403 - assert(f == k->has_finalizer(),"inconsistent has_finalizer") with debug VM
Description
When running in an environment in which code is invoked from maven -> junit -> mockit into test code, under 17015b33_x86_64 - odd NPEs are received in java.io.FileInputStream in attempting to close a file descriptor following a classloading attempt using a URLClassLoader.  It appears that instance fields are not getting set on object creation properly.  When trying later versions of the JDK, including this latest version of 7u40, instead of the NPEs we get core dumps - for every attempted execution.  

I've saved the core dump file if you need it. 

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/classFileParser.cpp:3878
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/HUDSON/workspace/jdk7u40-2-build-linux-amd64-product/jdk7u40/hotspot/src/share/vm/classfile/classFileParser.cpp:3878), pid=26007, tid=140004061697792
#  assert(f == k->has_finalizer()) failed: inconsistent has_finalizer
#
# JRE version: Java(TM) SE Runtime Environment (7.0_40-b29) (build 1.7.0_40-ea-fastdebug-b29)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b48-fastdebug mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: /weblogic/dev/src_maven/modules/application-archive/core or core.26007 (max size 1048576 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /weblogic/dev/src_maven/modules/application-archive/hs_err_pid26007.log
Phoning home... 
Using server: 10.161.186.18, port 4711
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#
Current thread is 140004061697792
Dumping core ...
Aborted (core dumped)
Comments
Is the core file available, if so could you attach to the bug? Can you reproduce the crash with -XX:TraceRedefineClasses=268435455 and attach the output?
25-06-2013
Changing from an empty method body to a non-empty method body doesn't violate the JVMTI spec. But the JVM TI spec doesn't account for special cases like finalize() for which instrumentation should perhaps have been disallowed. Without looking at the code (or asking someone about it) I don't know of any way to determine exactly what redefinition is being attempted. Not sure if there is some JVM TI tracing info that might be available.
19-06-2013
Can that be determined from the error logs or the dump? I have no viable way of knowing otherwise. (I'm not getting a report of the assertion -- I'm only getting the dump).
19-06-2013
Please check if the assertion is due to adding a non-empty finalizer. If so, I believe the jvmti spec does not allow you to add new methods, so perhaps we could disallow this.
18-06-2013
David - is this something we should file a bug report on with jmockit? If so, what should it say - that use of redefine classes to add non-empty finalize() methods can lead to assertion failures, and that no fix is currently available? (It's also odd that this only happens when running under maven, and not when going through the same junit/jmockit code straight on.). Thanks, Jim
17-06-2013
We've seen this assertion failure before when redefine classes is used to add a non-empty finalize() method to a class. The VM can't handle that. Need to find the existing CR number ....
17-06-2013
JDK-6904403 was closed as will-not-fix because it was only seen with an artificial testcase. I still feel this is not something that should be supported, but unfortunately the JVM TI spec is far too loose with regards to what changes should be allowable and which should not.
17-06-2013