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

David Smiley commented on LUCENE-5152:
--------------------------------------

I've been bitten by bugs in my code related to sharing BytesRefs.  It's not 
clear in the APIs who "owns" a BytesRef received from a method call.  In other 
words, can a recipient know wether it can safely cache it for use later or 
wether it's not safe because it could change suddenly later.  It's not even 
just that since there are two levels of ownership, the BytesRef instance and 
then the underlying char array.  This could be partially addressed with more 
documentation; I did that in my own code but that didn't stop another bug.  

I have a rough idea in which a BytesRef has a boolean flag or two to indicate 
how share-able it is, and then a conditional clone method that either returns 
the current instance or returns shallow copy, or does a deep copy depending on 
those flags.  I dunno, just a half-baked idea.
                
> Lucene FST is not immutable
> ---------------------------
>
>                 Key: LUCENE-5152
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5152
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: core/FSTs
>    Affects Versions: 4.4
>            Reporter: Simon Willnauer
>            Priority: Blocker
>             Fix For: 5.0, 4.5
>
>         Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch
>
>
> a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned 
> output from and FST (BytesRef) which caused sideffects in later execution. 
> I added an assertion into the FST that checks if a cached root arc is 
> modified and in-fact this happens for instance in our MemoryPostingsFormat 
> and I bet we find more places. We need to think about how to make this less 
> trappy since it can cause bugs that are super hard to find.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to