Description of problem:

We are running into a JDK crash, I can reproduce the same crash with Eclipse and IntelliJ. The crash occurs after code hotswap.

I wasn't able to reproduce the crash with javac and jdb: the crash is seen during a call to StackFrame.thisObject() and I didn't find a way to call this with jdb.

The crash log lists the following stack trace:

Stack: [0x00007f6fc1626000,0x00007f6fc1726000], sp=0x00007f6fc1723c30, free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0xa9e82b] GenerateOopMap::error_work(char const*, __va_list_tag*)+0x125
V [libjvm.so+0xa9e92c] GenerateOopMap::report_error(char const*, ...)+0xa6
V [libjvm.so+0xa9e9a7] GenerateOopMap::verify_error(char const*, ...)+0x77
V [libjvm.so+0xa9a8ed] GenerateOopMap::init_basic_blocks()+0x243
V [libjvm.so+0xa9a630] GenerateOopMap::do_interpretation()+0xb8
V [libjvm.so+0xa9e678] GenerateOopMap::compute_map(Thread*)+0x4be
V [libjvm.so+0x103d106] OopMapForCacheEntry::compute_map(Thread*)+0xfe
V [libjvm.so+0x103dd39] OopMapCacheEntry::fill(methodHandle const&, int)+0xdd
V [libjvm.so+0x103ebed] OopMapCache::compute_one_oop_map(methodHandle const&, int, InterpreterOopMap*)+0x4d
V [libjvm.so+0xf99f24] Method::mask_for(int, InterpreterOopMap*)+0x78
V [libjvm.so+0x13c296d] interpretedVFrame::stack_data(bool) const+0x77
V [libjvm.so+0x13c28d3] interpretedVFrame::locals() const+0x1d
V [libjvm.so+0xdd9d2d] VM_GetOrSetLocal::check_slot_type_no_lvt(javaVFrame*)+0xbf
V [libjvm.so+0xdd9fa2] VM_GetOrSetLocal::doit()+0x118
V [libjvm.so+0x13e4031] VM_Operation::evaluate()+0xe1
V [libjvm.so+0x14484c4] VMThread::evaluate_operation(VM_Operation*)+0x62
V [libjvm.so+0x1448cb9] VMThread::inner_execute(VM_Operation*)+0x30f
V [libjvm.so+0x1449065] VMThread::loop()+0x117
V [libjvm.so+0x1448062] VMThread::run()+0xfc
V [libjvm.so+0x133b207] Thread::call_run()+0x195
V [libjvm.so+0x104fc85] thread_native_entry(Thread*)+0x199

From what I've debugged in Eclipse (I cannot say about IntelliJ), the operations that are done would look like this in jdb:

stop at EclipseHotswapCrash$GlyphLayout:25
run

1. change "ab" to "abc" in the source file, recompile
   pop
   redefine EclipseHotswapCrash$GlyphLayout EclipseHotswapCrash$GlyphLayout.class
   step into
2. StackFrame.thisObject() is called to update stack frame labels

Version-Release number of selected component (if applicable):

OpenJDK 17.0.6

How reproducible:

IntelliJ steps to Reproduce:
1. Debug the snippet with breakpoint at line 25.
2. On the main thread, at the paused stack frame, right-click -> Reset Frame.
3. Change the string at line 22 from "ab" to "abc", save.
4. Build, accept reloading classes.
5. Step into.

Eclipse steps to Reproduce:
1. Debug the snippet with breakpoint at line 25.
2. Change the string at line 22 from "ab" to "abc", save.

Actual results:

The JDK crashes.

Expected results:

No crash, debugging works as expected.

Additional info:

See my comment here (there is some more info on the ticket as well): https://github.com/eclipse-jdt/eclipse.jdt.debug/issues/227#issuecomment-1491007209

Originally the bug was reported here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=565537

I've reported a bug via: https://bugreport.java.com/bugreport/