JDK-8149743 : JVM crash after debugger hotswap with lambdas
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8u72,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-02-12
  • Updated: 2016-11-02
  • Resolved: 2016-02-24
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 8 JDK 9
8u102Fixed 9 b110Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
import java.io.IOException;
import java.util.Arrays;

public class Main {

   public static void main(String[] args) throws IOException {
       while (true) {
           System.in.read();
           Integer[] array = new Integer[0]; //breakpoint here
           //Arrays.stream(array).filter(i -> i % 2 == 0);
       }
   }
}

Steps to reproduce:
1. run in debug mode
2. uncomment the line with Arrays...
3. compile/hot swap
4. add a breakpoint
Crash

Fastdebug build fails with assert:
#  assert(i >= 0 && i< _length) failed: oob: 0 <= 2 < 2

At GetClassMethods:2283
int original_index = instanceK_h->method_ordering()->at(index);

V  [libjvm.so+0x968bfd]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V  [libjvm.so+0xe2cd70]  JvmtiEnv::GetClassMethods(oop, int*, _jmethodID***)+0x3c0
V  [libjvm.so+0xdcc7e7]  jvmti_GetClassMethods+0x207
C  [libjdwp.so+0x731b]  methods1+0x7b
C  [libjdwp.so+0x1101c]  debugLoop_run+0x27c
C  [libjdwp.so+0x22ec5]  attachThread+0x25
V  [libjvm.so+0xe572a8]  JvmtiAgentThread::call_start_function()+0x158
V  [libjvm.so+0x13425b9]  JavaThread::thread_main_inner()+0x1c9
V  [libjvm.so+0x1342816]  JavaThread::run()+0x1c6
V  [libjvm.so+0x10cd612]  java_start(Thread*)+0xd2
C  [libpthread.so.0+0x74a4]  start_thread+0xc4


Comments
Nice find of the old bug: JDK-5060160 RedefineClasses should swap _method_ordering IK field There are a few of those old JVM/TI RedefineClasses() bugs that date back to the original SCA based Serviceability team. In particular there are bugs tracking issues that were found during the RedefineClasses code crawl from back in the 2000's...
23-02-2016

this looks like an old issue that we didn't know if it still existed.
22-02-2016

Moving from hotspot/runtime -> hotspot/jvmti.
19-02-2016

An array tracking method ordering is not swapped when we swap methods between the old class being redefined and the scratch class it is being redefined into.
18-02-2016

The lambda adds a synthetic method. Hotswap doesn't support adding or deleting methods, or changing their signatures. VM_RedefineClasses::compare_and_normalize_class_version normally throws a JVMTI_ERROR_UNSUPPORTED_REDEFINITION_METHOD_ADDED if a method is added, but it seems to think it is OK in some cases: http://hg.openjdk.java.net/jdk9/dev/hotspot/file/tip/src/share/vm/prims/jvmtiRedefineClasses.cpp#l805 // method added, see if it is OK Which it seems to think it is in this case. But then we crash, so apparently it's not.
12-02-2016