Mailing-List: contact pylucene-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: pylucene-dev@lucene.apache.org
Date: Mon, 25 Jun 2012 05:12:42 +0000 (UTC)
From: "Patrick J. McNerthney (JIRA)" <jira@apache.org>
To: pylucene-dev@lucene.apache.org
Message-ID: <52771206.49962.1340601162813.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <46055193.34558.1333051462328.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (PYLUCENE-17) Possible race condition with
 pylucene attachCurrentThread
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Patrick J. McNerthney commented on PYLUCENE-17:
-----------------------------------------------

Your diff.17.txt patch works against my test also.

There is still one small part of this initialization process that concerns me. The class static fields are initialized after the class$ value is set. This introduces the following possibility:

1. Thread A calls initializeClass, finds class$ to be null and starts to initialize it.
2. Thread A sets class$ to it's value.
3. Before Thread A set the class static fields to their values, Thread B interrupts it starts executing. 
4. Thread B calls initializeClass, finds class$ have it's value and returns.
5. Thread B then accesses one or more of that classes static fields, getting 0 or NULL values instead of their proper values.

I initially attempted to instead set class$ after the initialization of the class static fields, but realized that there is a recursive issue that required establishing class$ before the class static fields are initialized. The Boolean class is a good example, where the TRUE and FALSE fields instantiate Boolean instances, causing the initializeClass function to be called again. I suppose it is also possible that a class static field of a different type might end up being initialized, and that class could then instantiate a static field memory of the original type.

My latest attachment enhances your patch with what I believe is a way to allow for the recursion that occurs when the class static fields are initialized when the class$ has not been set.

Let me know if this makes sense to you.
                
> Possible race condition with pylucene attachCurrentThread
> ---------------------------------------------------------
>
>                 Key: PYLUCENE-17
>                 URL: https://issues.apache.org/jira/browse/PYLUCENE-17
>             Project: PyLucene
>          Issue Type: Bug
>         Environment: Linux 2.6.39
> Sun jdk 1.6.26
>            Reporter: Greg Bowyer
>              Labels: pylucene
>         Attachments: PYLUCENE-17-3.patch, backtrace, diff.17.txt, lucene-threadtest.py
>
>
> It looks like there is a possible race that can cause null pointer exceptions in the JVM, making it crash
> Because its a race it is hard to reproduce, the best luck I have had so far is dropping my FS cache in the OS, which seems to slow down the initialisation of the JVM enough to make it easier to reproduce.
> Attached is my test case
> Test session follows
> ---------------------------------------------------------------
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f79226b35c8, pid=26581, tid=140158003312384
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4b05c8]  instanceKlass::cached_itable_index(unsigned long)+0x18
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid26581.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ rm -r /tmp/test-index/
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> [thread 139988165344768 also had an error][thread 139988165344768 also had an error]#
> #  SIGSEGV (0xb)
>  at pc=0x00007f5197550a29, pid=27657, tid=139988039468800
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4f2a29]  unsigned+0x299
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid27657.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> greg@localhost ~/programming/python $ sudo bash -c 'echo 3 > /proc/sys/vm/drop_caches'
> greg@localhost ~/programming/python $ python ./lucene-threadtest.py 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007f51bc2eaa1e, pid=28124, tid=139988377052928
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x4f2a1e]  unsigned+0x28e
> #
> # An error report file with more information is saved as:
> # /home/greg/programming/python/hs_err_pid28124.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> #
> Aborted (core dumped)
> greg@localhost ~/programming/python $ 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira