Version 2.0.38 and 2.0.39 Crash on Alpine Linux

[eolivelli]

I am trying to upgrade an application that used Netty TC Native 2.0.33.Final to a new version of the Application that now uses 2.0.38 (with 2.0.39 the behaviour is the same).

Basically the JVM crashes with the dump below.

More context:

• the application is NoSQLBench
• it is using Netty because imported by Apache Pulsar Java Client, that relocates Netty and TCNative classes and libraries
• the application runs on a Docker image based on openjdk:15-alpine

hs_err dump:

Current thread (0x00005588430b46c0):  JavaThread "scenarios:001" [_thread_in_native, id=48, stack(0x00007fea33879000,0x00007fea33979aa8)]

Stack: [0x00007fea33879000,0x00007fea33979aa8],  sp=0x00007fea33975318,  free space=1008k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000000000003efe
C  [liborg_apache_pulsar_shade_netty_transport_native_epoll_x86_64800468828061674979.so+0xb4d7]  netty_jni_util_JNI_OnLoad+0x67
C  [libjava.so+0xf4bd]  Java_jdk_internal_loader_NativeLibraries_load+0xdd
j  jdk.internal.loader.NativeLibraries.load(Ljdk/internal/loader/NativeLibraries$NativeLibraryImpl;Ljava/lang/String;ZZ)Z+0 java.base@15-ea
j  jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open()Z+57 java.base@15-ea
j  jdk.internal.loader.NativeLibraries.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)Ljdk/internal/loader/NativeLibrary;+256 java.base@15-ea
j  jdk.internal.loader.NativeLibraries.loadLibrary(Ljava/lang/Class;Ljava/io/File;)Ljdk/internal/loader/NativeLibrary;+51 java.base@15-ea
j  java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/io/File;)Ljdk/internal/loader/NativeLibrary;+31 java.base@15-ea
j  java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+61 java.base@15-ea
j  java.lang.System.load(Ljava/lang/String;)V+7 java.base@15-ea
j  org.apache.pulsar.shade.io.netty.util.internal.NativeLibraryUtil.loadLibrary(Ljava/lang/String;Z)V+5
v  ~StubRoutines::call_stub
V  [libjvm.so+0x75dbe2]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x2a2
V  [libjvm.so+0xb8066b]  invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) [clone .constprop.126]+0x85b
V  [libjvm.so+0xb81156]  Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*)+0x106
V  [libjvm.so+0x814c83]  JVM_InvokeMethod+0xf3
j  jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base@15-ea

[eolivelli]

I will be happy to give more information as needed or perform other tests.

It looks like it is kind of a blocker for upgrading Netty

[eolivelli]

it looks like that the problem is more about "epoll" and not about tc-native.

and also it looks like that with adoptopenjdk/openjdk15:alpine-slim docker image the problem does not reproduce

[normanmaurer]

@eolivelli let me know once you have a reproducer and I will have a look!

[eolivelli]

sure

[eolivelli]

I will try to create a self-contained patch with a simple Dockerfile and something who uses Apache Pulsar Java client

[normanmaurer]

Any update ?

[eolivelli]

sorry, I was caught by other priorities.

We switched to adoptopenjdk/openjdk15:alpine-slim (instead of openjdk:15-alpine) we the problem disappeared

I believe that we can close this issue

[normanmaurer]

Thanks a lot!