JDK-8035150 : ShouldNotReachHere() in ConstantPool::copy_entry_to
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2014-02-18
  • Updated: 2015-08-28
  • Resolved: 2014-02-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 8u20 b04Fixed 9Fixed
Related Reports
Duplicate :  
JDK-8044227 - Profiling Eclipse crashes JVM: ShouldNotReachHere() in constantPool.cpp:1351
Relates :  
JDK-8133636 - [TEST_BUG] Import/add tests for the problem seen in 8076110
Relates :  
JDK-8034785 - Assert when recursively trying to take the monitor from JVMTI MonitorContendedEnter
Description
NetBeans profiling agent runs into the following problem:

https://bugzilla-attachments-240763.netbeans.org/bugzilla/attachment.cgi?id=144898

More details in the NetBeans bug:

https://netbeans.org/bugzilla/show_bug.cgi?id=240763
Comments
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
Release team: Approved for deferral.
25-02-2014
I think this patch fixes the problem. Running tests... diff --git a/src/share/vm/oops/constantPool.cpp b/src/share/vm/oops/constantPool.cpp --- a/src/share/vm/oops/constantPool.cpp +++ b/src/share/vm/oops/constantPool.cpp @@ -1295,6 +1295,7 @@ } break; case JVM_CONSTANT_UnresolvedClass: + case JVM_CONSTANT_UnresolvedClassInError: { // Can be resolved after checking tag, so check the slot first. CPSlot entry = from_cp->slot_at(from_i);
20-02-2014
This is indeed a JVM problem. Attached is a small repro which will crash the JVM in JDK8 (but not in JDK7). Unzip the file and run: ./runnit.sh
20-02-2014
ILW=HMH=P1, Crash, Always in the described context, No known workaround We are not yet completely sure that this is an issue in the VM and not in NetBeans. But until we know more we assume that it is a VM issue. 8-defer-request-justification: While this is a P1 crash, we don't think this is important enough to block 8. This happens only while debugging and might very well be a NetBeans issue as opposed to a VM one.
19-02-2014
Here is the stack trace for problem #3: Stack: [0x00000001201c3000,0x00000001202c3000], sp=0x00000001202c15b0, free space=1017k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x560340] VMError::report_and_die()+0x40a V [libjvm.dylib+0x1d37ff] report_vm_error(char const*, int, char const*, char const*)+0x54 V [libjvm.dylib+0x1cf958] ConstantPool::copy_entry_to(constantPoolHandle, int, constantPoolHandle, int, Thread*)+0x342 V [libjvm.dylib+0x37054e] VM_RedefineClasses::merge_constant_pools(constantPoolHandle, constantPoolHandle, constantPoolHandle*, int*, Thread*)+0x3ca V [libjvm.dylib+0x371661] VM_RedefineClasses::merge_cp_and_rewrite(instanceKlassHandle, instanceKlassHandle, Thread*)+0x3e7 V [libjvm.dylib+0x3727a1] VM_RedefineClasses::load_new_class_versions(Thread*)+0x743 V [libjvm.dylib+0x36883f] VM_RedefineClasses::doit_prologue()+0x9d V [libjvm.dylib+0x56671d] VMThread::execute(VM_Operation*)+0x4f V [libjvm.dylib+0x356264] JvmtiEnv::RedefineClasses(int, _jvmtiClassDefinition const*)+0x28 V [libjvm.dylib+0x324834] jvmti_RedefineClasses+0xc9 C [libprofilerinterface.jnilib+0x2add] Java_org_netbeans_lib_profiler_server_system_Classes_doRedefineClasses+0x210 J 1772 org.netbeans.lib.profiler.server.system.Classes.doRedefineClasses([Ljava/lang/Class;[[B)I (0 bytes) @ 0x00000001040a5395 [0x00000001040a52c0+0xd5] J 3353 C1 org.netbeans.lib.profiler.server.system.Classes.redefineClasses([Ljava/lang/Class;[[B)V (173 bytes) @ 0x000000010437835c [0x00000001043781a0+0x1bc] J 4155 C1 org.netbeans.lib.profiler.server.ProfilerInterface.redefineClasses([Ljava/lang/Class;[[B)V (129 bytes) @ 0x0000000103fd4b8c [0x0000000103fd4340+0x84c] J 3970 C1 org.netbeans.lib.profiler.server.ProfilerInterface.instrumentMethodGroupNow(Lorg/netbeans/lib/profiler/wireprotocol/InstrumentMethodGroupData;)V (668 bytes) @ 0x000000010460815c [0x0000000104606e20+0x133c] j org.netbeans.lib.profiler.server.ProfilerInterface.instrumentMethods(Lorg/netbeans/lib/profiler/wireprotocol/InstrumentMethodGroupCommand;)V+11 j org.netbeans.lib.profiler.server.ProfilerServer$1InstrumentMethodGroupThread.run()V+4
18-02-2014
I have worked on reproducing this and ran into a number of different problems. I have been running on OS X, although I don't think that makes a difference. #1) The profiler is calling the JVMTI method GetMethodDeclaringClass with a method id that is not valid. I can���t tell why the method id is invalid, but it is likely that the class it belongs to has been unloaded. Because of the perm-gen removal project, method ids and class unloading may behave differently in jdk8 than in jdk7. It tried running with -XX:-ClassUnloading to see if that helped and I then get further, but run into problem #2: #2) Assert when recursively trying to take the monitor from JVMTI MonitorContendedEnter, which I filed JDK-8034785 for. This will only show up in a debug build (since it is an assert), but still shows that something is bad. The current thinking in that bug is that a profiler should not recursively take locks from MonitorContendedEnter (although the spec is vague in this area). So to avoid this assert, I ran with a product build and then I run into problem #3: #3) ShouldNotReachHere() in constantPool.cpp:1351. This is what the bug report was originally opened for. This looks like it happens while walking the constant pool while redefining a class. Possibly the constant pool is incorrect or the redefine class logic is incorrect.
18-02-2014