OpenJDK在OpenHarmony上异常问题分析

0.前言

基于OpenHarmony的2022.06.30 master之前版本OpenJDK测试OK，但是之后版本测试报异常错误。

1.问题日志打印

2.报错日志代码分析

src/java.base/unix/native/libjli/java_md_common.c

jclass
FindBootStrapClass(JNIEnv *env, const char* classname)
{
   if (findBootClass == NULL) {
       findBootClass = (FindClassFromBootLoader_t *)dlsym(RTLD_DEFAULT,
          "JVM_FindClassFromBootLoader");
       if (findBootClass == NULL) {
           JLI_ReportErrorMessage(DLL_ERROR4,
               "JVM_FindClassFromBootLoader");
           return NULL;
       }
   }
   return findBootClass(env, classname);
}

问题分析：
dlsym(RTLD_DEFAULT, “JVM_FindClassFromBootLoader”); 返回了NULL，导致异常；基于dlsym的RTLD_DEFAULT有问题；OpenHarmony中没有dlsym的RTLD_DEFAULT的使用，但是OpenJDK中有大量的使用；

dlsym(RTLD_DEFAULT, name);
也就是说，handle=RTLD_DEFAULT，在网上查了下，这种情况下会发生的事情是，会在当前进程中按照 default library search order搜索name这个symbol，网上的介绍摘录如下：
http://www.qnx.de/developers/docs/6.4.0/neutrino/lib_ref/d/dlsym.html?lang=cn
If handle is a handle returned by dlopen(), you must not have closed that shared object by calling dlclose(). The dlsym() functions also searches for the named symbol in the objects loaded as part of the dependencies for that object.
If handle is RTLD_DEFAULT, dlsym() searches all objects in the current process, in load-order.
In the case of RTLD_DEFAULT, if the objects being searched were loaded with dlopen(), dlsym() searches the object only if the caller is part of the same dependency hierarchy, or if the object was loaded with global search access (using the RTLD_GLOBAL mode).

3.问题解决方案

社区修改了musl的libc的导致，提问题给社区：
https://gitee.com/openharmony/third_party_musl/issues/I5FJ0O
社区在musl中解决方案：
https://gitee.com/openharmony/third_party_musl/pulls/371