libjdwp crash while debugging application ran on OpenJDK 16

[Stefan Karlsson]

Hi Simeon,

On 2021-06-23 12:39, S A wrote:
> Hi all,
>
> my colleagues recently ran into a crash in libjdwp, when measuring
> performance with OpenJDK 17 (early access build). The same crash was
> observed with OpenJDK 16.0.1, but not with OpenJDK 15.
>
> We are hoping to get a fix for the crash, before the official OpenJDK 17
> release. We've opened a RHEL bugzilla ticket for this (
> https://bugzilla.redhat.com/show_bug.cgi?id=1972529), but we expect this
> won't be enough to resolve the crash before the release.
>
> What would the appropriate medium be to report the problem? I assume this
> mailing list is not the right place, but I don't know how to otherwise
> reach out to OpenJDK developers and maintainers (other than via RHEL
> support/bugzilla, which is often a slow process).

The hs_err crash files usually states where to report the bugs. 
Oracle-built binaries say:
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp

I think serviceability-dev would be the be the correct mailing list. 
I'll bcc away jdk-dev and will move this to serviceablity-dev.

I wonder if this could be caused by calling commonRef_unpin on a ref 
that is not "pinned"? Specifically, look at the updated weakenNode:

static jweak
weakenNode(JNIEnv *env, RefNode *node)
{
     if (node->strongCount == 1) {
...
         return weakRef;
     } else {
         node->strongCount--;
         return node->ref;
     }
}

if strongCount is 0, this will underflow and then delete node will take 
the wrong path:

if (node->strongCount != 0) {
   JNI_FUNC_PTR(env,DeleteGlobalRef)(env, node->ref);
} else {
   JNI_FUNC_PTR(env,DeleteWeakGlobalRef)(env, node->ref);
}

The previous version of weakenNode looked like this:

static jweak
weakenNode(JNIEnv *env, RefNode *node)
{
     if (node->isStrong) {
...
         return weakRef;
     } else {
         return node->ref;
     }
}

so a unbalanced unpin call would previously not fail in the same way.

StefanK

>
> Sorry for the noise on the mailing list.
>
> Best regards,
> Simeon
>
> *Extra infos and background:*
>
> We would like to move to OpenJDK 17, in order to use Shenandoah GC.
> Shenandoah GC shows promising results for our product, though only with the
> fix for https://bugs.openjdk.java.net/browse/JDK-8254315. We would not be
> able to switch (or even evaluate the switch properly) until the crash is
> resolved.
>
> Unfortunately we have no reproducer outside of our product, and our
> reproducer is quite complex. Trivial use cases of debugging OpenJDK 16 with
> Eclipse (we base our product on Eclipse) do not run into a crash.
>
> A fast debug build for OpenJDK 16 reports an assertion fail as follows:
>
> #  Internal Error
> (/tmp/jep2604_fastdebug_jdk16/jdk16/src/hotspot/share/runtime/jniHandles.cpp:148),
> pid=81289, tid=56880
> #  assert(!is_jweak(handle)) failed: wrong method for detroying jweak
> #
> # JRE version: OpenJDK Runtime Environment (16.0) (fastdebug build
> 16-internal+0-adhoc.sandreev.jdk16)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug
> 16-internal+0-adhoc.sandreev.jdk16, mixed mode, tiered, compressed oops, g1
> gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x1043cb4]  JNIHandles::destroy_global(_jobject*)+0x224
> ...
> Stack: [0x00007ffe3c4f5000,0x00007ffe3c5f6000],  sp=0x00007ffe3c5f4be0,
>   free space=1022k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1043cb4]  JNIHandles::destroy_global(_jobject*)+0x224
> V  [libjvm.so+0xfafd9f]  jni_DeleteGlobalRef+0x10f
> C  [libjdwp.so+0xf11a]  deleteNode+0x7a
> C  [libjdwp.so+0xf71f]  commonRef_reset+0x6f
> C  [libjdwp.so+0x10dec]  debugInit_reset+0x6c
> C  [libjdwp.so+0x270a2]  acceptThread+0xa2
> V  [libjvm.so+0x127c054]  JvmtiAgentThread::call_start_function()+0x1d4
> V  [libjvm.so+0x1a51e9a]  JavaThread::thread_main_inner()+0x5ba
> V  [libjvm.so+0x1a589e0]  Thread::call_run()+0x100
> V  [libjvm.so+0x15fbd26]  thread_native_entry(Thread*)+0x116
>
> Going through the stack trace, looking for related changes, I've not been
> able to reproduce the crash with this commit reverted:
> https://github.com/openjdk/jdk/commit/79f1dfb8d3941377da77e73f7bbab93baef29b8e