[
https://issues.apache.org/jira/browse/LUCENE-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794680#action_12794680
]
Uwe Schindler edited comment on LUCENE-2084 at 12/27/09 12:36 PM:
------------------------------------------------------------------
I found one place where the arrayOffset() bug occurs:
- Create an ByteBuffer by wrapping another byte[] with offset and length.
- use ByteBuffer.slice() to create an independednt buffer which position()==0
the current position of the prev ByteBuffer (which is the wrapped byte[]). This
buffer will have an arrayOffset() of the original offset (which is position=0
in this buffer). The limit/cpacity of this buffer is the above length, which is
remaining() on the original buffer.
The length formula is the definitely wrong, if would sometimes undeflow and
give negative numbers, e.g. if the position() of the sliced buffer if e.g. 5
(so arrayoffset==5 in the slice) and the remaining bytes are e.g. 3 => length
in the code before/after tha patch is -2.
I will provide a testcase later that shows both bugs (position() and
arrayOffset() misuse).
was (Author: thetaphi):
I found one place where the arrayOffset() buf occurs:
- Create an ByteBuffer by wrapping another byte[] with offset and length.
- use ByteBuffer.slice() to create an independednt buffer which position()==0
the current position of the prev ByteBuffer (which is the wrapped byte[]). This
buffer will have an arrayOffset() of the original offset (which is position=0
in this buffer). The limit/cpacity of this buffer is the above length, which is
remaining() on the original buffer.
The length formula is the definitely wrong, if would sometimes undeflow and
give negative numbers, e.g. if the position() of the sliced buffer if e.g. 5
(so arrayoffset==5 in the slice) and the remaining bytes are e.g. 3 => length
in the code before/after tha patch is -2.
I will provide a testcase later that shows both bugs (position() and
arrayOffset() misuse).
> remove Byte/CharBuffer wrapping for collation key generation
> ------------------------------------------------------------
>
> Key: LUCENE-2084
> URL: https://issues.apache.org/jira/browse/LUCENE-2084
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/*
> Reporter: Robert Muir
> Assignee: Robert Muir
> Priority: Minor
> Fix For: 3.1
>
> Attachments: collation.benchmark.tar.bz2, LUCENE-2084.patch,
> LUCENE-2084.patch, LUCENE-2084.patch, TopTFWikipediaWords.tar.bz2
>
>
> We can remove the overhead of ByteBuffer and CharBuffer wrapping in
> CollationKeyFilter and ICUCollationKeyFilter.
> this patch moves the logic in IndexableBinaryStringTools into char[],int,int
> and byte[],int,int based methods, with the previous Byte/CharBuffer methods
> delegating to these.
> Previously, the Byte/CharBuffer methods required a backing array anyway.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
