JDK-8227582 : runtime/TLS/testtls.sh fails on x86_32
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-07-11
  • Updated: 2020-01-31
  • Resolved: 2019-07-12
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.
JDK 14
14 b06Fixed
Related Reports
Relates :  
Description
The test was introduced with JDK-8225035. It is part of tier1 profile, which makes tier1 fail on x86_32.

$ CONF=linux-x86-server-fastdebug make images run-test TEST=runtime/TLS/testtls.sh

...

Running test with -XX:-AdjustStackSizeForTLS ...
[0.002s][info][os,thread] Capturing initial stack in primordial thread: req. size: 320K, actual size: 320K, top=0xffe94000, bottom=0xffe44000
[0.003s][info][os,thread] Thread attached (tid: 17191, pthread id: 4118595328).
[0.009s][warning][os,thread] Failed to start thread - pthread_create failed (EINVAL) for attributes: stacksize: 512k, guardsize: 4k, detached.
[0.011s][info   ][os,thread] Number of threads approx. running in the VM: 0
[0.011s][info   ][os,thread] rlimit: STACK 8192k, CORE 0k, NPROC 256786, NOFILE 10000, AS infinity, DATA infinity, FSIZE infinity
[0.011s][info   ][os,thread] Memory: 4k page, physical 65908860k(5486640k free), swap 25165820k(24709408k free)
[0.011s][info   ][os,thread] 
[0.012s][info   ][os,thread] /proc/sys/kernel/threads-max (system-wide limit on the number of threads):
[0.012s][info   ][os,thread] 513573
[0.012s][info   ][os,thread] 
[0.012s][info   ][os,thread] 
[0.012s][info   ][os,thread] /proc/sys/vm/max_map_count (maximum number of memory map areas a process may have):
[0.012s][info   ][os,thread] 65530
[0.012s][info   ][os,thread] 
[0.012s][info   ][os,thread] 
[0.012s][info   ][os,thread] /proc/sys/kernel/pid_max (system-wide limit on number of process identifiers):
[0.012s][info   ][os,thread] 131072
[0.012s][info   ][os,thread] 
[0.012s][info   ][os,thread] 
[0.012s][info   ][os,thread] container (cgroup) information:
[0.012s][info   ][os,thread] container_type: cgroupv1
[0.012s][info   ][os,thread] cpu_cpuset_cpus: 0-31
[0.012s][info   ][os,thread] cpu_memory_nodes: 0-1
[0.012s][info   ][os,thread] active_processor_count: 32
[0.012s][info   ][os,thread] cpu_quota: no quota
[0.012s][info   ][os,thread] cpu_period: 100000
[0.012s][info   ][os,thread] cpu_shares: no shares
[0.012s][info   ][os,thread] memory_limit_in_bytes: unlimited
[0.012s][info   ][os,thread] memory_and_swap_limit_in_bytes: not supported
[0.012s][info   ][os,thread] memory_soft_limit_in_bytes: unlimited
[0.012s][info   ][os,thread] memory_usage_in_bytes: 45068341248
[0.012s][info   ][os,thread] memory_max_usage_in_bytes: 57913733120
[0.012s][info   ][os,thread] 
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Cannot create worker GC thread. Out of system resources.
# An error report file with more information is saved as:
# /home/buildbot/worker/jdkX-linux/build/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_tier1/scratch/0/hs_err_pid17191.log
STDERR:
openjdk version "14-testing" 2020-03-17
OpenJDK Runtime Environment (fastdebug build 14-testing+0-builds.shipilev.net-openjdk-jdk-b930-20190709-jdk-1328)
OpenJDK Server VM (fastdebug build 14-testing+0-builds.shipilev.net-openjdk-jdk-b930-20190709-jdk-1328, mixed mode)
rerun:
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/c659942fc471 User: jiangli Date: 2019-07-12 17:40:12 +0000
12-07-2019

Aleksey, thanks for the log! According to the log, the test is "Running test with -XX:-AdjustStackSizeForTLS ... ". It's the negative test case, which expects it to fail. However, in this failure instance, it fails with SEGV. I expressed some concerns about the negative test case with potential different failure modes during the OpenJDK mailing list discussion. So the question is, can we make the jtreg test case to accept the SEGV. If not, we could turn off the negative test case, but that would be the last resort.
11-07-2019