[jira] [Commented] (PYLUCENE-17) Possible race condition with pylucene attachCurrentThread

["Andi Vajda (Commented) (JIRA)" <ji...@apache.org>]

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

Andi Vajda commented on PYLUCENE-17:
------------------------------------

Yes, this makes sense. Looking at your backtrace a definite possibility is the class$ static variable on each of the C++ wrapper classes generated for a Java class. These are unprotected (oops) and could lead to such a race condition when multiple threads are all bootstrapping the code.
I should at least mark it 'volatile' or whatever the construct is in C++ to ensure that the variable, when read, is reflecting the shared reality of all the threads.
It is ok, but wasteful, to have multiple threads repeatedly/concurrently initialize the class$ and mids$ arrays for all the classes being loaded. It is not ok for a class$ to be reported not NULL yet being seen as NULL at other times. The class$ object, a jclass handle (the size of a pointer) must be read atomically and reliably. I believe the fix should be trivial if my theory is correct and the right C++ primitive exists (I believe so, I have to check). Add a mutex around class$ would be a big slowdown.
If it turns out that the class$ variable should not be shared across threads (I could imagine Classloader tricks readily defeating this sharing), then it would have to be moved to thread-local storage, which would slow down thread initialization a bit since the class$ and mids$ caching would have to be reproduced for each thread. This may be in fact the safest fix.

An incomplete workaround would be to have the main thread run the code being run by all the other threads first.
A complete workaround would be to have the main thread force-initialize all the classes needed by the code being run in other threads.

                
> 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: backtrace, 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