See the bug for more investigation. The symptom of the problem is apparent `SIGSEGV` in `dlerror`. We were able to debug it to older glibc issue, which makes `dlerror` not thread-safe when pthreads are not yet loaded. This bug seems to uniquely affect custom launchers. We figured this is because custom launchers are not linked with `pthread`. JLI seems to be avoiding this issue, because it does link with `pthread`. Therefore the fix on the JDK side is to always link custom launchers with `pthread`.
Reproducing the issue is a bit awkward. It requires compiling with older GCC (7.3.1 in my case), so that `libsimdsort` would not expose `avx2_sort` symbol, so that compiler stub initialization sequence would get its own erroneous `dlerror`, which would conflict inside of glibc. The compilations with newer GCC (10, at very least) are not exposed to this. This is why the issue is so elusive. But now that we understand it, we know this is a ticking time bomb that can fire at any time in the future, once any concurrent thread inside of VM gets a non-zero `dlerror` for whatever reason. Additional testing: - [x] Linux AArch64 server fastdebug, `sun/management/jmxremote/bootstrap/CustomLauncherTest.java`, 100x, no failures - [x] Linux AArch64 server fastdebug, `tools/jpackage`, 20x, no failures ------------- Commit messages: - Change to LIB* variables - Fix Changes: https://git.openjdk.org/jdk/pull/26978/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26978&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345810 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26978.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26978/head:pull/26978 PR: https://git.openjdk.org/jdk/pull/26978
