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

[Roger Riggs]

Hi,

If just doubling the size of the Reaper stack would suffice, I would 
start there.

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.
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