Message11277

>I'm still not exactly clear what happens the the OutOfMemoryError or StackOverflowError

I think it's StackOverflowError, but I suppose under heavy memory load the former one could cause a similar phenomenon.

Actually I wasn't able to detect the Error explicitly "in field", but the attached Test.java can provoke the explained behavior (You'll have to run it several times, but it runs fast and I observe the issue every 5th run or so, so it's still easy to reproduce).

Additionally, the fact that xss-value can affect likeliness of the issue supports the StackOverflowError thesis.

If you run Test.java often enough you will observe something like this:

...
recursion 4607
recursion 4608
recursion 4609
recursion 4610
recursion 4611java.lang.Stacjava.lang.StackOverflowErrorjava.lang.StackOverflowErrorjava.lang.StackOverflowError
4608
10619136
10628355
continue normal execution...

If the checksums (10619136, 10628355) differ some finally blocks were bypassed; note that the difference is 4609+4610, which belong to the frames that were also dropped by the catch: It printed 4608. The construct as a whole however still resumes normal execution.

I am currently not able to pin down how this program structure is exactly embedded in guava, but I am convinced it is present there in manifold ways (which is why we observed various slightly different deadlocks).