JDK-8240187 : Test hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java fails on Alpine Linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: repo-portola
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: other
  • CPU: x86_64
  • Submitted: 2020-02-27
  • Updated: 2021-06-28
  • Resolved: 2021-06-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
repo-portolaResolved
Related Reports
Duplicate :  
JDK-8247589 - Implementation of Alpine Linux/x64 Port
Relates :  
JDK-8247589 - Implementation of Alpine Linux/x64 Port
Relates :  
JDK-8205878 - pthread_getcpuclockid is expected to return 0 code
Description
JDK-8205878 adds check that pthread_getcpuclockid() can return ESRCH for invalid thread id [1].
According to the specification: "ERRORS ESRCH  No thread with the ID thread could be found."

This works because pthread_getcpuclockid() in glibc checks the passed thread id [2], [3].

However, this is not the case for musl libc which does not check the passed thread id [4]. For more details see discussion on musl mail list [5]. 

It looks like the thread id needs to be checked to be valid for muls libc.

[1] https://hg.openjdk.java.net/jdk/jdk/file/e6336e3c5984/src/hotspot/os/linux/os_linux.cpp#l5736
[2] https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_getcpuclockid.c;h=5dadc95817479b4049c1f0d09947ec10b2b1e887;hb=HEAD#l30
[3] https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthreadP.h;h=06fb0d74c5c5941dc6a96a44a938ad265838b049;hb=HEAD#l256
[4] https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_getcpuclockid.c
[5] https://www.openwall.com/lists/musl/2020/02/10/6
Comments
Only issues with associated changesets should be closed as "Fixed". If this issue has been solved by JDK-8247589, then this bug should be closed as a duplicate of JDK-8247589.
28-06-2021
The test is excluded from musl as part of the fix JDK-8247589 https://github.com/openjdk/jdk/commit/63009f90ec7df053c936226663b463b8584364a9#diff-e0e4bf341de1ea938f6ef451583b0a7e2bbc6f8c60f03f0a68ee0db2311bd52eR31
28-06-2021
[~avoitylov] has this issue been fixed? Should this bug be closed? Thanks
25-06-2021
this test is fixed as part of http://cr.openjdk.java.net/~avoitylov/webrev.8247589/
23-07-2020
Crash dump is attached. The fix with test exclusion is sent to portola-dev mail list: http://mail.openjdk.java.net/pipermail/portola-dev/2020-February/000436.html
28-02-2020
> JDK-8205878 adds check that pthread_getcpuclockid() can return ESRCH for invalid thread id [1]. Not quite. We found that on Linux pthread_getcpuclockid() can return ESRCH for invalid thread id (contrary to POSIX spec) and so had to accommodate that in the code. IIUC from the referenced discussions the problem is that part of the test results in undefined behaviour if we pass the pthread_t to any pthread function after it has terminated - specifically pthread_getcpuclockid(). In glibc this results in the ESRCH. In musl I assume it crashes. This is unfortunate. There is no way to know that an arbitrary pthread_t refers to a live thread or not. The purpose of the test is simply check the resilience of the VM when erroneously given a bad pthread_t. I suggest skipping the test if running on musl.
27-02-2020