Endless loops in computation code (1.6.0_22).

[Tom Rodriguez]

After watching maven download jars for 10 minutes, it actually ran the test and reproduced it.  I put together a little main to run the test manually and just reproduced it with -XX:+PrintCompilation.  It hung right after it printed this:

  3%      org.jsuffixarrays.DivSufSort::sortTypeBstar @ 979 (1125 bytes)

so it's possible it's a bug with with on stack replacement.  I've reproduced it with the latest 1.7 as well so it's something we haven't seen before.  I filed 7024475 for this and put you on the interest list.  I can't reproduce it in 6u12 but I can in 6u14 so I think it appeared there.

tom

On Mar 3, 2011, at 2:14 PM, Dawid Weiss wrote:

> 
> This must be a hotspot bug, Tom, it's insane. So.
> 
> I've created a branch to run all the tests in sequence and dump loop counters to stdout. There's also -XX:PrintCompilation so that you can see what got compiled. So, do these:
> 
> git pull
> git co JVM_BUG
> 
> the problematic loop now looks like this:
> 
>             int c0, c1 = 0;
>             // ...
>             for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0)
>             {
>                 for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1)
>                 {
>                     System.err.println("C0: " + c0 + " C1: " + c1);
>                     i = bucket_B[(c0) * ALPHABET_SIZE + (c1)];
>                     if (1 < (j - i))
>                     {
>                         ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m - 1));
>                     }
>                 }
>             }
> 
> even not knowing what other elements are, c0 and c1 are local variables that are not modified anywhere inside the loop other than decremented on every loop run (inside and outside). The output is as one would expect, from the start:
> 
> C0: 254 C1: 255
> C0: 253 C1: 255
> C0: 253 C1: 254
> C0: 252 C1: 255
> C0: 252 C1: 254
> C0: 252 C1: 253
> ...
> 
> so both counters are decrement... until this happens (run 1):
> 
> ...
> C0: 74 C1: 77
> C0: 74 C1: 76
> C0: 74 C1: 75
> C0: 254 C1: 255
> C0: 254 C1: 255
> [forever]
> 
> And run2, for example:
> ...
> C0: 68 C1: 70
> C0: 68 C1: 69
> C0: 254 C1: 255
> C0: 254 C1: 255
> C0: 254 C1: 255
> 
> note that counter values:
> 
> C0: 254 C1: 255
> 
> are actually what it all started with, but why it'd never decrement again is beyond me.
> 
> The compilation dump shows that nothing special happens before the code falls into an endless loop (I assume stdout writes are sequential when they go via Maven's test plugin, but don't know for sure).
> 
> I also checked with:
> 
> java version "1.7.0-ea"
> Java(TM) SE Runtime Environment (build 1.7.0-ea-b104)
> Java HotSpot(TM) 64-Bit Server VM (build 19.0-b05, mixed mode)
> 
> and it exhibits the same problem. Sadly, I don't know how to use gdb to hack into a running VM instance to inspect what is actually happening, but if I can be of any further help, let me know.
> 
> Dawid
> 
> On Thu, Mar 3, 2011 at 10:39 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>  
> Inserting the breakpoint would deopt the code and you'll resume in the interpreter so you'll end up avoiding the JITed code which presumably is where the bug is.
> 
> Yep, I realize this is the case, I even mentioned it in my original post. Let me double check that we're not doing something non-deterministic first though... but if you'd like to try then...
>  
> I agree.  It sounds like we're screwing up the bounds somehow.  Is there a jar file I can grab to run this test easily?
> 
> Mind this is happening infrequently (but on different machines, different OSs, etc.).  Here's the procedure:
> 
> git clone git at github.com:carrotsearch/jsuffixarrays.git
> cd jsuffixarrays
> # while (true)? {
> mvn test
> # }
> 
> I've just done the above and it hung on the first execution... the next one it didn't, the third one it did again. So maybe it is happening more frequently than less. The JRE I did it on is:
> 
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
> 
> But it applies to newer versions as well.
> 
> The particular class that is causing this is DivSufSort (DivSufSortTest), but I don't know what causes this to happen, so I'd run all of them (these are parallel testng tests).
>  
> I also didn't check with the trunk HotSpot, so it may be something that's already been fixed.
> 
> Dawid
> 
>