Bug ID: JDK-8288547 Could not find Java_java_lang_ClassLoader_00024NativeLibrary

Type: Bug
Component: core-libs
Sub-Component: java.lang
Affected Version: 11.0.15

Priority: P3
Status: Closed
Resolution: Not an Issue
OS: generic
CPU: generic

Submitted: 2022-06-08
Updated: 2022-12-10
Resolved: 2022-12-10

ADDITIONAL SYSTEM INFORMATION :
Docker container with centos 7 and java-11-openjdk-11.0.15.0.9-2.el7_9

A DESCRIPTION OF THE PROBLEM :
We are seeing this message in our logs every few seconds, and its flooding our log console. It could be related to changes in the following commit.
https://github.com/openjdk/jdk11u/commit/f7346f087a14f1878029a00104005e04468d333f#comments
https://github.com/openjdk/jdk11u-dev/commit/f7346f087a14f1878029a00104005e04468d333f

REGRESSION : Last worked in version 11


FREQUENCY : often

This is not a JDK issue. Previously, async-profiler tried to intercept newly loaded libraries by hooking JNI implementation of NativeLibrary.load. Unfortunately, there is no standard supported API to do that. Some time ago, as I found the signatures of NativeLibrary methods quite unstable (they changed back and forth even in minor JDK updates), I finally gave up playing version guessing game and completely rewrote the hooking mechanism in async-profiler 2.7 (released in February 2022). Now it does not rely on NativeLibrary internals. The customer who reported the issue needs to update to a new version of async-profiler. I believe there is nothing more to do regarding this issue, and it can be closed.
26-08-2022
JDK-8275703 introduced the change of Java_java_lang_ClassLoader_00024NativeLibrary_load0 parameter list in 11.0.15 from JNIEXPORT jboolean JNICALL Java_java_lang_ClassLoader_00024NativeLibrary_load0 (JNIEnv env, jobject this, jstring name, jboolean isBuiltin) to JNIEXPORT jboolean JNICALL Java_java_lang_ClassLoader_00024NativeLibrary_load0 (JNIEnv env, jobject this, jstring name, jboolean isBuiltin, jboolean throwExceptionIfFail) one more boolean argument
25-08-2022
Looks like the method signature change to NativeLibrary load0 in 11.0.15 , see https://bugs.openjdk.org/browse/JDK-8275703 (one boolean parameter more now) does not work well together with the checks done here https://github.com/jvm-profiling-tools/async-profiler/blob/5312a793ec22106420883e8a274d10c390e6e4b1/src/profiler.cpp#L590 So async-profiler needs updating .
25-08-2022
The javaagent contains async-profiler. Looks to me like async-profiler tries to intercept NativeLibrary::load resp. NativeLibrary::load0 via RegisterNatives: https://github.com/jvm-profiling-tools/async-profiler/blob/5312a793ec22106420883e8a274d10c390e6e4b1/src/profiler.cpp#L582-L615 by swapping the native implementation of hotspot with its own implementation, thereby intercepting load library calls. Apart from this being just scary, I assume the logic is or was broken at some point and that broken version got packaged here.
24-08-2022
I find it likely that it has nothing to do with the OpenJDK. Got interested since we get reports for SapMachine as well. I ran the repro case (https://github.com/santipyx/oracle-9170972) provided by the reporter, and analyzed the container. Version: root@65a8a466d6f5:/# java -version openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment 18.9 (build 11.0.15+10) OpenJDK 64-Bit Server VM 18.9 (build 11.0.15+10, mixed mode, sharing) (whatever the parent container, maven something, packages. Very likely just whatever Debian ships) The repro case starts spring boot example with an Amazon-built agent containing the async profiler. If I remove that javaagent from the command line and start the app, the errors disappear.
24-08-2022
Requested java -version output from the submitter.
20-08-2022
I think this issue needs `java -version` output so that it's clear which JDK build this.
16-06-2022
Additional information from the submitter: We are working on reproducing the problem and we will send you more information as soon as possible.
16-06-2022
Requested a simple reproducer from the submitter.
09-06-2022