[ 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