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.
s'marks
More information about the core-libs-dev
mailing list