RFR 8157592: StackTraceLogging fails with stack overflow on 32-bit Windows

[George Triantafillou]

Hi David,

I did an experiment by printing the stack depth at smaller intervals and 
running TestThrowable.java with 
-XX:AbortVMOnException=java.lang.StackOverflowError.  In one failing 
run, there were 1888 recursions.  Here's the stack of the failing thread 
from the hs_err file:

Stack: [0x15980000,0x159d0000],  sp=0x1598b9bc,  free space=46k

If you divide by the stack size on windows 32, that amounts to 
approximately 173 bytes per frame, which doesn’t seem unreasonable.

(gdb) print (0x159d0000-0x15980000)/1888
$2 = 173

Factor in that the frames are compiled, which use less space than 
interpreted and whether the frames are compiled in time for the test to 
run can also add variability.  C2 optimizes stack usage more than C1, 
and the test case appears to compile these methods with C1. Also, when 
run with jtreg, there are frames on the stack for the jtreg test framework.

The stack usage for this test isn’t unreasonable.  There’s no change to 
stack usage that would have made this test fail now.  It’s just normal 
variability on 32-bit Windows:

java -XX:+PrintFlagsFinal -version | grep Stack | grep Pages

intx StackRedPages                             = 1
intx StackShadowPages                          = 9
intx StackYellowPages                          = 3

13*4k = 52k which results in stack overflow.

-George

On 6/9/2016 9:08 PM, David Holmes wrote:
> Hi George,
>
> On 10/06/2016 4:09 AM, George Triantafillou wrote:
>> Please review this small change to fix test failures on 32-bit Windows.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8157592
>> Open webrev: http://cr.openjdk.java.net/~gtriantafill/8157592/webrev/
>> <http://cr.openjdk.java.net/%7Egtriantafill/8157592/webrev/>
>>
>> TestThrowable.java: Added catch for intermittent StackOverflowError
>> errors on 32-bit Windows.
>
> This does not seem to be addressing the problem - why do we suddenly 
> start getting SOE when running this test? I asked that question in the 
> bug report. If something has changed to trigger this then we need to 
> ensure that change was intended/desirable and then look at how to 
> adjust the test - not simply catch the SOE and ignore it.
>
> Thanks,
> David
> -----
>
>
>> StackTraceLogging.java: Removed unused updateEnvironment method.
>>
>> Tested locally on 32-bit Windows as well as RBT.
>>
>> -George
>>