Message11282

Okay, with James' hints I was able to write a new minimal example showing how finally blocks can be bypassed ... actually. See Test2.java

The trick is as follows: After catching a StackOverflowError, the finally block performs a method-call. Even if the called method is empty, this can sometimes directly trigger another StackOverflowError, because the stack is already near to exhaustion. (In the example I let the dummy-method call itself twice so the stack expands slightly more, which makes the issue occur literally always.)

You will find that it outputs something like

Start...
continue normal execution... 7924

which means that some resource would not have been successfully cleaned up. (Otherwise it would be "continue normal execution... 0")

I guess that an increased xss somehow lets the JVM manage stack memory in larger blocks, so it is more resilient if the finally block requires additional stack; however this is a pure guess.

The real question is:
Why is the StackOverflowError happening in the finally block (?) not thrown? AFAIK exceptions raised in catch or finally blocks should propagate up the stack, e.g. see http://stackoverflow.com/questions/3779285/exception-thrown-in-catch-and-finally-clause

So this behavior is definitely somehow fishy.