From david.holmes at oracle.com Mon Mar 2 00:02:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 2 Mar 2020 10:02:33 +1000 Subject: RFR: 8240187: Test hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java fails on Alpine Linux In-Reply-To: <17A4DB39-6B6B-4CB3-A1B5-8D5FEB11C59E@oracle.com> References: <9e83f65f-74b7-4c0d-f190-7eecefec51c0@bell-sw.com> <17A4DB39-6B6B-4CB3-A1B5-8D5FEB11C59E@oracle.com> Message-ID: On 29/02/2020 8:29 pm, Mikael Vidstedt wrote: > Is it only pthread_getcpuclockid() that is the problem, or are the other functions also problematic. Put differently, should the whole test be excluded, or are the parts of the test that still make sense to run on musl? Anything that leads to calling a pthread function is potentially a problem. Doing the analysis to see which sub-tests might do that would be rather tedious IMO and not a particularly good use of ones time IMO. Further the parts that aren't affected also aren't utilising musl, so the test adds nothing to musl testing in that regard. Cheers, David > Cheers, > Mikael > >> On Feb 27, 2020, at 11:20 PM, Alexander Scherbatiy wrote: >> >> Hello, >> >> The hotspot test TestTerminatedThread.java fails on Alpine Linux because pthread_getcpuclockid() from musl libc library does not check that the passed thread id is valid (see discussion on musl mail list [1]). >> >> The proposed fix skips the test for the musl glibc library as it is suggested in the JDK-8240187 comments [1]. >> >> http://cr.openjdk.java.net/~alexsch/8240187/webrev.00/ >> >> >> [1] https://www.openwall.com/lists/musl/2020/02/10/6 >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8240187 >> >> >> Thanks, >> >> Alexander. >> > From alexander.scherbatiy at bell-sw.com Tue Mar 3 14:25:14 2020 From: alexander.scherbatiy at bell-sw.com (Alexander Scherbatiy) Date: Tue, 3 Mar 2020 17:25:14 +0300 Subject: Fix for test/jdk/tools/jpackage/share/JavaOptionsTest.java on Alpine Linux In-Reply-To: <7F323D55-5EE0-495B-8658-4960E33DAEEE@oracle.com> References: <09811137-1459-3e29-7bdc-c4b81b9e2991@bell-sw.com> <7F323D55-5EE0-495B-8658-4960E33DAEEE@oracle.com> Message-ID: On 22.02.2020 03:49, Mikael Vidstedt wrote: > Looping in the AIX folks for good luck. > > I sorta expected the ?hack? of enabling that re-execution in the launcher would bite back at some point, but at the time it seemed like the simple thing to do. At the time I even went down the rabbit hole of exploring the option of merging libjava.so and libjvm.so, but not sure that?s really practical or in the end even solves the problem. > > Assuming 1. is the ?Right Way(tm)?, why wouldn?t we do that? :) Sharing the code would of course be nice, but worst case some duplication may be the better option? RequiresSetenv(jvmpath) always returns true with musl libc so the code responsible for the launcher re-execution is located in CreateExecutionEnvironment method [1]. To duplicate it that is necessary to read jvmpath which requires GetJVMPath, GetJREPath methods. It looks like a lot of code should be copied. Here is one more version which sets _JAVA_LAUNCHER_REEXEC environment variable if the launcher is re-executed and does not add java options one more time in jpackage if the variable is set: http://cr.openjdk.java.net/~alexsch/portola/tests/jpackage/webrev.02 [1] https://hg.openjdk.java.net/portola/portola/file/7ff60204a181/src/java.base/unix/native/libjli/java_md_solinux.c#l415 Thanks, Alexander. > > Cheers, > Mikael > >> On Feb 20, 2020, at 5:29 AM, Alexander Scherbatiy wrote: >> >> >> Hello, >> >> Short description: >> >> JavaOptionsTest.java test creates a jar file with a simple Hello java class, packages it into a native app and calls it. >> >> JLI reexecutes the native app on Linux Alpine and because of this java options are doubled when passed to Hello application. >> >> The proposed fix adds java options only if the application arguments does not contain them: >> >> http://cr.openjdk.java.net/~alexsch/portola/tests/jpackage/webrev.01 >> >> >> Detailed description: >> >> The native app first calls start_launcher() method from src/jdk.incubator.jpackage/share/native/libapplauncher/main.cpp file which uses Package::SetCommandLineArguments() to store provided arguments in FBootFields->FArgs field. Next it calls RunVM(). >> >> JavaVirtualMachine::launchVM() method stores both java options and arguments from FBootFields->FArgs into jvm args list and calls javaLibrary.JavaVMCreate() so the provided args are passed to the java application. >> >> This path is different on Alpine Linux which sets LD_LIBRARY_PATH and JLI decides to invoke start_launcher() one more time with the updated library path (see [1]). >> >> This time all java options are passed to start_launcher() method, they stored in FBootFields->FArgs and concatenated with java options passed to JavaVirtualMachine::launchVM() method. >> >> So jvm options are stored twice in case the launcher decides to reexec itself. >> >> Possible solutions: >> >> 1. The right way would be to detect that the JLI is reexecuted in the same way as it does JLI (see [2]). It has some complicated logic in ContainsLibJVM() method and the code needs to be shared between java.base and jdk.incubator.jpackage modules. >> >> 2. Using a static variable to check that the jpackage is executed the second time. It does not work because the jpackage is executed by as a new process by execve(). >> >> Here are two subsequent calls of execve() on Alpine Linux from strace log: >> >> ----- >> >> execve("./output/test/bin/test", ["./output/test/bin/test", "-Dparam2=test2"], 0x7fff98259778 /* 8 vars */) = 0 >> >> execve("/root/mount/repos/branch-portola-dev/jtreg/alpine/app/output/test/bin/test", ["./output/test/bin/test", "-Djava.library.path=/root/mount/"..., "-Djava.l >> arch_prctl(ARCH_SET_FS, 0x7f42a0298d48) = 0 >> >> ----- >> >> Java options are passed to the second app call there jpackage adds them one more time. >> >> >> 3. Check in some way that the app arguments already contain java options and to not add them the second time. >> >> The proposed fix converts the app arguments to std::set. I tried to use std::unordered_set but got the error message: >> >> "#error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options." >> >> Actually java options are always set first for vmargs so it is also possible only to check that if the app arguments list starts with java options list. It relies on the way how java options are passed to jpackage and it can be fragile. >> >> >> May be it has sense to check the app arguments and java options only if LIBC is defined and it equals to musl. >> >> One more interesting question is if the test passes on AIX because AIX also requires the modified LD_LIBRARY_PATH and the test should fail for the same reason. >> >> >> [1] https://hg.openjdk.java.net/portola/portola/file/7ff60204a181/src/java.base/unix/native/libjli/java_md_solinux.c#l85 >> >> [2] https://hg.openjdk.java.net/portola/portola/file/7ff60204a181/src/java.base/unix/native/libjli/java_md_solinux.c#l306 >> >> Thanks, >> >> Alexander. >>