You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Robert Muir (JIRA)" <ji...@apache.org> on 2014/03/17 06:49:44 UTC

[jira] [Updated] (LUCENE-5532) AutomatonQuery.hashCode is not thread safe

     [ https://issues.apache.org/jira/browse/LUCENE-5532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Muir updated LUCENE-5532:
--------------------------------

    Attachment: LUCENE-5532.patch

Here's a test for the thread safety bug, fails like this:
{noformat}
Caused by: java.lang.NullPointerException
	at org.apache.lucene.util.automaton.Automaton.getNumberOfTransitions(Automaton.java:543)
	at org.apache.lucene.search.AutomatonQuery.hashCode(AutomatonQuery.java:84)
	at org.apache.lucene.search.TestAutomatonQuery$1.run(TestAutomatonQuery.java:228)
{noformat}

this patch takes a different approach: it doesnt assert "same language" at all, thats expensive and I don't think its nearly as important as things like being thread-safe, hashcode being consistent with equals, etc.

So we just impl hashcode/equals with the compiled form. If the automata have the same structure (e.g. same regex or wildcard), it will return true. The previous stuff was overkill anyway, because  e.g. foo* would not equate to foo** since the "term" is different!

I also made getNumberedStates a little less trappy, even though its no longer used here by this stuff.

> AutomatonQuery.hashCode is not thread safe
> ------------------------------------------
>
>                 Key: LUCENE-5532
>                 URL: https://issues.apache.org/jira/browse/LUCENE-5532
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
>         Attachments: LUCENE-5532.patch
>
>
> This hashCode is implemented based on  #states and #transitions.
> These methods use getNumberedStates() though, which may oversize itself during construction and then "size down" when its done. But numberedStates is prematurely set (before its "ready"), which can cause a hashCode call from another thread to see a corrupt state... causing things like NPEs from null states and other strangeness. I don't think we should set this variable until its "finished".



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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