[
https://issues.apache.org/jira/browse/LUCENE-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2975:
----------------------------------
Attachment: LUCENE-2975.patch
As the loop is now hardcoded and never iterates more than 5 or 9 times, we
should add an assert after the last byte is read. Its highest bit must bei 0,
else there would follow more bytes which should not happen.
This can lead to problems if you have no symmetry between writeVLong and
readVLong (instead use readVInt).
> 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, 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]
