RFR 8241053: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test fails on Alpine Linux with debug build

[Dmitry Samersoff]

Hello Thomas,

 > Since I am here I have a question about muslc, if I may:

musl libc doesn't have some features that glibc has (e.g. dlvsym), so, 
from code perspective, you can build musl version on glibc linux but not 
vice versa.

 From runtime perspective, you can't run binaries compiled for one 
platform on the other one because it requires different runtime linkers 
for load (/lib/ld-musl-x86_64.so.1 vs /lib64/ld-linux-x86-64.so.2)

So if you have strict requirement to run the same binaries on both 
platforms you need to bundle correct libc with JDK.

-Dmitry


On 05.08.2020 10:33, Thomas Stüfe wrote:
> Fix looks good to me too (though you already have your two reviewers).
> 
> Since I am here I have a question about muslc, if I may:
> 
> Is there a way to execute code conditionally for glibc only? I ran into
> this question a couple of times in the past. Related to that, would that
> have to be a runtime check or would a compile time check sufficient? (In
> other words, should a JDK built for linux x64 be runnable on distros with
> muslc as well as glibc?)
> 
> Thank you!
> 
> ..Thomas
> 
> On Tue, Aug 4, 2020 at 11:13 AM Alexander Scherbatiy <
> alexander.scherbatiy at bell-sw.com> wrote:
> 
>> Could you review the updated fix:
>>     http://cr.openjdk.java.net/~alexsch/8241053/webrev.01
>>
>> The assert_status() and the thread cleanup is moved under the "if
>> (status != 0)" check.
>>
>> Thanks,
>> Alexander.
>>
>> On 04.08.2020 01:51, David Holmes wrote:
>>> Hi Alexander,
>>>
>>> Thanks for fixing this.
>>>
>>> On 4/08/2020 1:33 am, Alexander Scherbatiy wrote:
>>>> Hello,
>>>>
>>>> Could you review the fix for the issue:
>>>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8241053
>>>>     Webrev: http://cr.openjdk.java.net/~alexsch/8241053/weberv.00
>>>
>>> I would simplify this a little:
>>>
>>>     assert_status(status == 0 || status == EINVAL, status,
>>> "pthread_attr_setstacksize");
>>>     // pthread_attr_setstacksize() function can fail
>>>     // if the stack size exceeds a system-imposed limit.
>>>     if (status == EINVAL) {
>>>
>>> to
>>>     if (status != 0) {
>>>       // pthread_attr_setstacksize() function can fail
>>>       // if the stack size exceeds a system-imposed limit.
>>>       assert_status(status == EINVAL, status,
>>> "pthread_attr_setstacksize");
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>
>>>> The following tests fail on Linux Alpine with musl libc:
>>>>     test/hotspot/jtreg/runtime/Thread/TestThreadStackSizes.java
>>>>
>> test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
>>
>>>>
>>>>
>>>> This is because muls pthread_attr_setstacksize(3) function
>>>> implementation [1] returns EINVAL when stack size exceeds the certain
>>>> limit.
>>>>
>>>> According to POSIX pthread_attr_setstacksize() function description [2]:
>>>>    The pthread_attr_setstacksize() function will fail if:
>>>>       [EINVAL]  The value of stacksize is less than PTHREAD_STACK_MIN
>>>> or exceeds a system-imposed limit.
>>>>
>>>> The proposed fix excludes EINVAL value from assert_status() and for
>>>> the EINVAL return value makes the same cleanup actions and returns
>>>> false from os::create_thread() function as it is done for AIX[3].
>>>>
>>>> To reproduce the issue it needs to build Portola from repository [4]
>>>> using instructions from JEP 386: Alpine Linux/x64 Port [5].
>>>> After the fix both TestThreadStackSizes.java and
>>>> TestOptionsWithRanges.java tests pass on Alpine Linux with musl libc
>>>> and on Ubuntu 18.0.4.
>>>>
>>>> [1]
>>>>
>> https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c
>>>>
>>>> [2]
>>>>
>> https://pubs.opengroup.org/onlinepubs/007908799/xsh/pthread_attr_setstacksize.html
>>>>
>>>> [3]
>>>>
>> https://hg.openjdk.java.net/jdk/jdk/file/c8102e6fc512/src/hotspot/os/aix/os_aix.cpp#l890
>>>>
>>>> [4] https://github.com/openjdk/portola
>>>> [5] https://openjdk.java.net/jeps/386
>>>>
>>>> Thanks,
>>>> Alexander.
>>>>
>>