JDK-8140520 : segfault on solaris-amd64 with "-XX:VMThreadStackSize=1" option
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_11
  • Submitted: 2015-10-26
  • Updated: 2021-10-01
  • Resolved: 2016-09-09
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 9
9 b138Fixed
Related Reports
Blocks :  
JDK-8136766 - Enable ThreadStackSize range test
Duplicate :  
JDK-8148169 - Test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails
Relates :  
JDK-8175342 - assert(InstanceKlass::cast(k)->is_initialized()) failed: need to increase java_thread_min_stack_allowed calculation
Relates :  
JDK-8274661 - Use system default for stack sizes
Relates :  
JDK-8161093 - Solaris for >8k pagesize adds extra guard pages
Relates :  
JDK-8204478 - VMThreadStackSize failing at max range
Relates :  
JDK-8140327 - segfault on solaris-amd64 with "-XX:CompilerThreadStackSize=1" option
Relates :  
JDK-8169373 - Work around linux NPTL stack guard error
Relates :  
JDK-8136766 - Enable ThreadStackSize range test
Description
TestOptionsWithRanges test failed during the PIT for JDK 9 b89 on solaris-amd64: 
TEST FAILED: Error processing option VMThreadStackSize with valid value '-XX:VMThreadStackSize=1'! JVM output reports a fatal error. JVM exited with code 6!
stdout content[#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xffff80fb36fa57b0, pid=18357, tid=19
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (build 1.9.0-internal-20151022232912.amurillo.jdk9-hs-2015-10--b00)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-internal-20151022232912.amurillo.jdk9-hs-2015-10--b00, mixed mode, tiered, compressed oops, g1 gc, solaris-amd64)
# Problematic frame:
# V  [libjvm.so+0x9a57b0]  MachNode*State::MachNodeGenerator(int)+0x16030
#
# Core dump will be written. Default location: /export/local/aurora/sandbox/results/workDir/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges/core or core.18357
#
# An error report file with more information is saved as:
# /export/local/aurora/sandbox/results/workDir/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges/hs_err_pid18357.log
Java start-up!
[error occurred during error reporting , id 0xb]

#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
]
stderr content[]

Running "java -XX:VMThreadStackSize=1" on the same host gave:
-bash-4.1$ ./java -XX:VMThreadStackSize=1
Segmentation Fault
-bash-4.1$ echo $?
139 

hs_err_pid18357.log and replay_pid18357.log are attached.

Similar error occurred for -XX:CompilerThreadStackSize=1. See https://bugs.openjdk.java.net/browse/JDK-8140327
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8a89084b51bc User: lana Date: 2016-09-28 20:43:19 +0000
28-09-2016
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e7203436d63d User: lana Date: 2016-09-28 20:43:13 +0000
28-09-2016
URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/e7203436d63d User: dcubed Date: 2016-09-09 21:14:10 +0000
09-09-2016
URL: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/8a89084b51bc User: dcubed Date: 2016-09-09 21:14:07 +0000
09-09-2016
Results from the latest version of the test: $ for file in */JTwork/runtime/Thread/TooSmallStackSize.jtr; do > echo $file > grep PASS $file | sed -e 's/^/ /' > done linux_i586_3.8-fastdebug-c2-hotspot_fast_runtime/JTwork/runtime/Thread/TooSmallStackSize.jtr PASSED: got expected error message with -XX:ThreadStackSize=16 PASSED: got expected error message with -XX:ThreadStackSize=32 PASSED: VM launched with -XX:ThreadStackSize=124 PASSED: got expected error message with -XX:CompilerThreadStackSize=16 PASSED: got expected error message with -XX:CompilerThreadStackSize=32 PASSED: VM launched with -XX:CompilerThreadStackSize=52 PASSED: got expected error message with -XX:VMThreadStackSize=16 PASSED: got expected error message with -XX:VMThreadStackSize=32 PASSED: VM launched with -XX:VMThreadStackSize=52 linux_x64_3.8-fastdebug-c2-hotspot_fast_runtime/JTwork/runtime/Thread/TooSmallStackSize.jtr PASSED: got expected error message with -XX:ThreadStackSize=16 PASSED: got expected error message with -XX:ThreadStackSize=32 PASSED: VM launched with -XX:ThreadStackSize=240 PASSED: got expected error message with -XX:CompilerThreadStackSize=16 PASSED: got expected error message with -XX:CompilerThreadStackSize=32 PASSED: VM launched with -XX:CompilerThreadStackSize=64 PASSED: got expected error message with -XX:VMThreadStackSize=16 PASSED: got expected error message with -XX:VMThreadStackSize=32 PASSED: VM launched with -XX:VMThreadStackSize=64 macosx_x64_10.9-fastdebug-c2-hotspot_fast_runtime/JTwork/runtime/Thread/TooSmallStackSize.jtr PASSED: got expected error message with -XX:ThreadStackSize=16 PASSED: got expected error message with -XX:ThreadStackSize=32 PASSED: VM launched with -XX:ThreadStackSize=240 PASSED: got expected error message with -XX:CompilerThreadStackSize=16 PASSED: got expected error message with -XX:CompilerThreadStackSize=32 PASSED: VM launched with -XX:CompilerThreadStackSize=64 PASSED: got expected error message with -XX:VMThreadStackSize=16 PASSED: got expected error message with -XX:VMThreadStackSize=32 PASSED: VM launched with -XX:VMThreadStackSize=64 solaris_sparcv9_5.11-fastdebug-c2-hotspot_fast_runtime/JTwork/runtime/Thread/TooSmallStackSize.jtr PASSED: got expected error message with -XX:ThreadStackSize=16 PASSED: got expected error message with -XX:ThreadStackSize=32 PASSED: VM launched with -XX:ThreadStackSize=248 PASSED: got expected error message with -XX:CompilerThreadStackSize=16 PASSED: got expected error message with -XX:CompilerThreadStackSize=32 PASSED: VM launched with -XX:CompilerThreadStackSize=128 PASSED: got expected error message with -XX:VMThreadStackSize=16 PASSED: got expected error message with -XX:VMThreadStackSize=32 PASSED: VM launched with -XX:VMThreadStackSize=128 solaris_x64_5.11-fastdebug-c2-hotspot_fast_runtime/JTwork/runtime/Thread/TooSmallStackSize.jtr PASSED: got expected error message with -XX:ThreadStackSize=16 PASSED: got expected error message with -XX:ThreadStackSize=32 PASSED: VM launched with -XX:ThreadStackSize=240 PASSED: got expected error message with -XX:CompilerThreadStackSize=16 PASSED: got expected error message with -XX:CompilerThreadStackSize=32 PASSED: VM launched with -XX:CompilerThreadStackSize=396 PASSED: got expected error message with -XX:VMThreadStackSize=16 PASSED: got expected error message with -XX:VMThreadStackSize=32 PASSED: VM launched with -XX:VMThreadStackSize=224 windows_i586_6.3-fastdebug-c2-hotspot_fast_runtime/JTwork/runtime/Thread/TooSmallStackSize.jtr PASSED: got exit_code == 0 with -XX:ThreadStackSize=16 PASSED: got exit_code == 0 with -XX:ThreadStackSize=32 PASSED: VM launched with -XX:ThreadStackSize=32 PASSED: got exit_code == 0 with -XX:CompilerThreadStackSize=16 PASSED: got exit_code == 0 with -XX:CompilerThreadStackSize=32 PASSED: VM launched with -XX:CompilerThreadStackSize=32 PASSED: got exit_code == 0 with -XX:VMThreadStackSize=16 PASSED: got exit_code == 0 with -XX:VMThreadStackSize=32 PASSED: VM launched with -XX:VMThreadStackSize=32 windows_x64_6.3-fastdebug-c2-hotspot_fast_runtime/JTwork/runtime/Thread/TooSmallStackSize.jtr PASSED: got exit_code == 0 with -XX:ThreadStackSize=16 PASSED: got exit_code == 0 with -XX:ThreadStackSize=32 PASSED: VM launched with -XX:ThreadStackSize=32 PASSED: got exit_code == 0 with -XX:CompilerThreadStackSize=16 PASSED: got exit_code == 0 with -XX:CompilerThreadStackSize=32 PASSED: VM launched with -XX:CompilerThreadStackSize=32 PASSED: got exit_code == 0 with -XX:VMThreadStackSize=16 PASSED: got exit_code == 0 with -XX:VMThreadStackSize=32 PASSED: VM launched with -XX:VMThreadStackSize=32
08-09-2016
[~kvn] I requested an FC extension because some of the internal reviewers felt that this is "an RFE that happens to fix a bug". In your role as "HotSpot Group Lead", I'm interpreting the previous comment as your agreement that this is a bug and not an RFE. Thank you! If you happen to have time, it would be nice if you can take a look at the changes. I believe you wrote the original code that shared the compiler thread minimum stack size with the VMThread minimum stack size a very long time ago... $ sp -r1.319 src/os/solaris/vm/os_solaris.cpp src/os/solaris/vm/SCCS/s.os_solaris.cpp: D 1.319 04/04/20 12:36:19 vkozlov 1091 1088 00024/00010/04080 MRs: COMMENTS: 5030087: Use VMThreadStackSize if CompilerThreadStackSize is not defined. Thanks!
07-09-2016
Why you need FC extension? It is clearly THE bug. It does not matter if changes are XL.
07-09-2016
FC Extension request Justification: This is a bug fix that required a lot of code to split the single thread_min_stack_allowed into three distinct values (java_thread_min_stack_allowed, compiler_thread_min_stack_allowed and vm_internal_thread_min_stack_allowed). The fix has gone through many (> 5) internal rounds of review and during that review process some of the reviewers felt this was an RFE that happened to fix a bug. Rather than continue to argue the point, I'm submitting this bug fix for an FC extension request. Risk: Very Low, a lot of code has been refactored, but the semantics are the same with the exception of Solaris X64 which needs a larger minimum compiler thread stack size. The risk of so much code refactoring has been mitigated by many review cycles by four engineers in addition to the original author. Due date: The patch is ready and reviewed internally and is being reviewed on OpenJDK, waiting for approval. Review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-September/020954.html
02-09-2016
Coleen filed JDK-8161093 during the code review of this fix.
09-08-2016
An examination of the code confirms the following: 1) the compiler thread shares a minimum size with the VM thread 2) in some cases the compiler thread stack size is the same value used for the VM thread
03-02-2016
The following is an excerpt of an email from Dmitry documenting some unexplained behavior related to this defect. >>>>> From the other hand I see that if CompilerThreadStackSize is not >>>>> defined then VMThreadStackSize is used for compiler thread. I tried >>>>> CompilerThreadStackSize option with VMThreadStackSize and noticed >>>>> that >>>>> segfault occurs only for CompilerThreadStackSize, i.e. following >>>>> commands are successfully executed: >>>>> java -XX:VMThreadStackSize=1 -XX:CompilerThreadStackSize=1024 >>>>> -version >>>>> java -XX:VMThreadStackSize=364 -XX:CompilerThreadStackSize=1024 >>>>> -version >>>>> >>>>> But following command got segfault: >>>>> java -XX:VMThreadStackSize=1024 -XX:CompilerThreadStackSize=364 >>>>> -version >>>> I'm going to bet that -XX:VMThreadStackSize=1 >>>> -XX:CompilerThreadStackSize=364 >>>> will segfault. >>>> >>>> >>>>> And following is successfully executed: >>>>> java -XX:VMThreadStackSize=1024 -XX:CompilerThreadStackSize=365 >>>>> -version >>>> I'm going to bet that -XX:VMThreadStackSize=1 >>>> -XX:CompilerThreadStackSize=365 >>>> will work. This data seems to indicate this issue is related to the compiler thread
03-02-2016
I posted this comment on an internal review thread. I'm repeating it here for "the OpenJDK record". On 1/5/16 11:54 AM, Daniel D. Daugherty wrote: > Couple of comments on this thread: > > 1) The fix for 8140327 was pushed back in mid-November so we can't > "reject the fix for 8140327". We can file a new bug if we think > that fix is wrong, but I don't think it is wrong. > > 2) The TestOptionsWithRanges.java test is trying to exercise the > range for the "-XX:VMThreadStackSize=N" option which is a good > thing to do in general, but not a good thing to do in the case > of this specific option. > > Here's where the option is defined: > > src/share/vm/runtime/globals.hpp > > product_pd(intx, ThreadStackSize, \ > "Thread Stack Size (in Kbytes)") \ > range(0, max_intx-os::vm_page_size()) \ > \ > product_pd(intx, VMThreadStackSize, \ > "Non-Java Thread Stack Size (in Kbytes)") \ > range(0, max_intx/(1 * K)) \ > \ > product_pd(intx, CompilerThreadStackSize, \ > "Compiler Thread Stack Size (in Kbytes)") \ > range(0, max_intx /(1 * K)) \ > > I'm intentionally showing all three *ThreadStackSize options here... > > BTW, I think the upper range for the '-XX:ThreadStackSize=N' option > is wrong. That option, like the other two *ThreadStackSize options, > is specified in K-bytes. The java man page says that the > '-XX:ThreadStackSize=N' option takes its size in bytes, but that > man page is wrong. The '-Xss' option and the '-XX:ThreadStackSize=N' > option both set the same internal value, but '-Xss' accepts a size > value in bytes and '-XX:ThreadStackSize=N' does not. I believe that > Ron filed a man page bug for that. > > So back to the '-XX:VMThreadStackSize=N' option... If N == 0, that > has the special meaning of using the default stack size. That's why > the lower end of the range is zero(0). However, that does NOT mean > that '-XX:ThreadStackSize=1' is necessarily a valid value. It > _might_ work on some platforms and not on other platforms. In this > case, it fails _sometimes_ on Solaris X64, but not always... > > Why is this? The minimum stack size needed to run the JVM is not > specified anywhere because it depends on so many different things. > The '-XX:ThreadStackSize=1' option might work on some Solaris X64 > configs and not on others because start-up ergonomics can change > a number of things... > > For folks that are trying to tune the Java thread stack size down, > we advise them to try different values with their application, but > not to be surprised if what worked in one Java release no longer > works in the next update (or release). > > > Ron's current fix for 8140520 is like the fix for 8140327 in that it > disables the range test for the '-XX:VMThreadStackSize=N' option. I'm > not aware of a better way to solve this problem given that the non-zero > lower bound for the '-XX:VMThreadStackSize=N' option is not defined. > > What I would like to see tested for all three *ThreadStackSize options: > > - a zero value test which exercises the default value > - a range test from '> default value' to the upper range > > However, I don't know how the test can programmatically query the > default value to know where to start the range test... > > Dan
05-01-2016
The fix is similar because the issue is similar. The test is testing for a for a minimum stack size which has no guaranteed minimum working value, a value of one for a stack size is not expected to work. The minimum stack size depends on many things which i will not enumerate here for fear that I leave something out.
21-12-2015
This bug with -XX:VMThreadStackSize=1' is very similar to the related bug with '-XX:CompilerThreadStackSize=1'. The solutions should be very similar: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/92f9ed54d9b2
16-12-2015
Thanks Dan. I dislike option values that mean "pretend this option doesn't really exist" :(
16-12-2015
@David - The '-XX:ThreadStackSize=0' and '-XX:VMThreadStackSize=0' options mean to use the system default.
15-12-2015
It makes no sense to say that the various StackSize flags have a minimum value of zero.
13-11-2015