RFR for JDK-8030284 TEST_BUG: intermittent StackOverflow in RMI bench/serial test

Stuart Marks stuart.marks at oracle.com
Fri Dec 20 03:06:04 UTC 2013

On 12/18/13 10:25 PM, Tristan Yan wrote:
> Hi Everyone
> Please help to review the fix for JDK-8030284.
> http://cr.openjdk.java.net/~tyan/JDK-8030284/webrev.00/
> <http://cr.openjdk.java.net/%7Etyan/JDK-8030284/webrev.00/>
> This is a one line fix that add -Xss to prevent StackOverflowError.

Hi, I guess this might make sense, but this still seems like a mystery to me.

Do we have any evidence that this test hit the stack limit but otherwise is 
behaving identically? It does load 50 classes recursively. It seems strange that 
this test apparently ran for years without problems as a shell test, but when 
run in a jtreg environment, adding the additional six or so stack frames for 
jtreg would have pushed it over the limit.

It's also kind of strange that in the two stack traces I've seen (I think I 
managed to capture only one in the bug report though) the StackOverflowError 
occurs on loading exactly the 50th class. Since we're observing intermittent 
behavior (happens sometimes but not others) the stack size is apparently 
variable. Since it's variable I'd expect to see it failing at different times, 
possibly the 49th or 48th recursive classload, not just the 50th. And in such 
circumstances, do we know what the default stack size is?

I don't know if you were able to reproduce this issue. If you were, it would be 
good to understand in more detail exactly what's going on.


More information about the core-libs-dev mailing list