[ 
https://issues.apache.org/jira/browse/LUCENE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008755#comment-13008755
 ] 

Dawid Weiss commented on LUCENE-2975:
-------------------------------------

We've recently hit an awesome JIT bug too...  There is a loop like this one:

{noformat}
            for (c0 = ALPHABET_SIZE - 2, j = m; 0 < j; --c0)
            {
                for (c1 = ALPHABET_SIZE - 1; c0 < c1; j = i, --c1)
                {
                    i = bucket_B[(c0) * ALPHABET_SIZE + (c1)];
                    if (1 < (j - i))
                    {
                        ssSort(PAb, i, j, buf, bufsize, 2, n, SA[i] == (m - 1));
                    }
                }
            }
{noformat}

c0 and c1 are local variables, so they are decreased on every loop round... but 
if the bug manifests itself c0 and c1 all of a sudden jump to some incredible 
values and never change, falling into an endless loop... Fun to watch.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7024475

I'm wondering how production systems can run flawlessly if such things exists 
out there ;)



> hotspot bug in readvint gives wrong results
> -------------------------------------------
>
>                 Key: LUCENE-2975
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2975
>             Project: Lucene - Java
>          Issue Type: Bug
>    Affects Versions: 3.1
>            Reporter: Uwe Schindler
>            Priority: Blocker
>             Fix For: 3.1
>
>         Attachments: LUCENE-2975.patch, LUCENE-2975.patch
>
>
> When testing the 3.1-RC1 made by Yonik on the PANGAEA (www.pangaea.de) 
> productive system I figured out that suddenly on a large segment (about 5 
> GiB) some stored fiels suddenly produce a strange deflate decompression 
> problem (CompressionTools) although the stored fields are no longer pre-3.0 
> compressed. It seems that the header of the stored field is read incorrectly 
> at the buffer boundary in MultiMMapDir and then FieldsReader just incorrectly 
> detects a deflate-compressed field (CompressionTools).
> The error occurs reproducible on CheckIndex with MMapDirectory, but not with 
> NIODir or SimpleDir. The FDT file of that segment is 2.6 GiB, on Solaris the 
> chunk size is Integer.MAX_VALUE, so we have 2 MultiMMap IndexInputs.
> Robert and me have the index ready as a tar file, we will do tests on our 
> local machines and hopefully solve the bug, maybe introduced by Robert's 
> recent changes to MMap.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to