Endless loops in computation code (1.6.0_22).

[Dawid Weiss]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20110303/2ed06ca8/attachment.html