[
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
