RFR (S) 6762191: Setting stack size to 16K causes segmentation fault
chris.plummer at oracle.com
Tue Nov 18 22:08:30 UTC 2014
Adding core-libs-dev at openjdk.java.net, since one of the changes is in
On 11/12/14 6:43 PM, David Holmes wrote:
> Hi Chris,
> Sorry for the delay.
> On 13/11/2014 5:44 AM, Chris Plummer wrote:
>> I'm still looking for reviewers.
> As the change is to the launcher it needs to be reviewed by the
> launcher owner - which I think is serviceability (though also cc'd
> Kumar :) ).
> Launcher change, and your rationale, seems okay to me. I'd probably
> put the test in to jdk/test/tools/launcher/ though.
>> On 11/7/14 7:53 PM, Chris Plummer wrote:
>>> This is an initial review for 6762191. I'm guessing there will be
>>> recommendations to fix in a different way, but thought this would be a
>>> good time to start the discussion.
>>> The bug is that if the -Xss size is set to something very small (like
>>> 16k), on linux there will be a crash due to overwriting the end of the
>>> stack. This happens before hotspot can compute its stack needs and
>>> verify that the stack is big enough.
>>> It didn't seem viable to move the hotspot stack size check earlier. It
>>> depends on too much other work done before that point, and the changes
>>> would have been disruptive. The stack size check is currently done in
>>> What is needed is a check before the thread is created. That way we
>>> can create a thread with a big enough stack to handle all needs up to
>>> the point of the check in os::init_2(). This initial check does not
>>> need to be the final check. It just needs to confirm that we have
>>> enough stack to get us to the check in os::init_2().
>>> I decided to check in java.c if the -Xss size is too small, and set it
>>> to a larger size if it is. I hard coded this size to 32k (I'll explain
>>> why 32k later). I suspect this is the part that will result in some
>>> debate. If you have better suggestions let me know. If it does stay
>>> here, then probably the 32k needs to be a #define, and maybe even an
>>> OS porting interface, but I'm not sure where to put it.
>>> The reason I chose 32k is because this is big enough for all platforms
>>> to get to the stack size check in os::init_2(). It is also smaller
>>> than the actual minimum stack size allowed on any platform. 32-bit
>>> windows has the smallest requirement at 64k. I add some printfs to
>>> print the minimum stack requirement, and then ran a simple JTReg test
>>> with every JPRT supported platform to get the results.
>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k,
>>> -Xss32k, and -XXss<minsize>, where <minsize> is the size from the
>>> error message produced by the JVM, such as in the following:
>>> $ java -Xss32k -version
>>> The stack size specified is too small, Specify at least 100k
>>> Error: Could not create the Java Virtual Machine.
>>> Error: A fatal exception has occurred. Program will exit.
>>> I ran this test through JPRT on all platforms, and they all pass.
>>> One thing to point out is that Windows behaves a bit different than
>>> the other platforms. It always rounds the stack size up to a multiple
>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On
>>> 32-bit Windows with C1, 64k is also the minimum requirement, so there
>>> is no error produced in this case. However, on 32-bit Windows with C2,
>>> 68k is the minimum, so an error is produced since the stack will only
>>> be 64k. There is no bug here. It's just a bit confusing.
More information about the core-libs-dev