RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

[Roger Riggs]

Hi David,


On 1/18/16 2:48 AM, David Holmes wrote:
> Hi Roger,
>
> On 16/01/2016 3:43 AM, Roger Riggs wrote:
>> Hi,
>>
>> If just doubling the size of the Reaper stack would suffice, I would
>> start there.
>
> That's too specific. It might be fix this problem case today, but 
> break again tomorrow.
I was suggesting a stopgap, though its not clear how long it would be 
needed.
>
>> If a mechanism (property) is needed to make an adjustment to the stack
>> size,
>> then I'd prefer something that applied to all Threads, not just the 
>> reaper.
>
> We already have means of changing other threads (eg -Xss for Java 
> threads) the problem here is that the process reaper thread stack size 
> is hard-wired. So we need some way to say control that.
I was targeting the increased stack size due to libc/glibc thread locals,
so it would be in addition to -Xss.

Roger


>
> David
> -----
>
>> It can be done in the Java code in Thread and would be low overhead 
>> and not
>> so a specialized bit of code that needs to be maintained and documented
>> for a single code path.
>>
>> We have seen other cases where the minimum stack size is not sufficient
>> when executing with various VM switch combinations.
>> Having an adjustment would address those to.
>>
>> $.02, Roger
>>
>>
>>
>> On 1/14/16 9:32 PM, David Holmes wrote:
>>> On 15/01/2016 4:59 AM, Martin Buchholz wrote:
>>>> The process grim reaper ends up being the first point of failure since
>>>> it tries not to waste the user's memory and it's in a core library,
>>>> but in principle it's not special.  I think a more general workaround
>>>> would be to add a hotspot flag that would add a memory safety zone to
>>>> all threads.  If it's known that TLS is stealing 32k from every
>>>> thread's stack, then the flag should ensure that every thread stack is
>>>> 32k larger.
>>>
>>> I think we need a point fix for the process reaper case in the
>>> immediate term. We can then consider how to better address the general
>>> case in the medium to long term.
>>>
>>>> More generally, I was hoping that hotspot would ensure that the -Xss
>>>> size was available for actual java stack frames and OS overhead was
>>>> added on automatically, but that is hard to implement, so the best
>>>> alternative workaround is for users to be able to specify that
>>>> additional stack size padding.  Maybe -XX:StackSizeOverhead=32768 ?
>>>
>>> Even this is still a band-aid - the user has to experience the
>>> problem, recognize it, and then figure out the right adjustment to
>>> add. Plus if any third-party library uses native TLS the requirement
>>> could change dynamically.
>>>
>>> So I'd prefer a new RFE to look at this general issue.
>>>
>>> Thanks,
>>> David
>>