[
https://issues.apache.org/jira/browse/PYLUCENE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400221#comment-13400221
]
Patrick J. McNerthney commented on PYLUCENE-17:
-----------------------------------------------
"I'm working on integrating your fix but via another route that doesn't involve
changing the code generator but instead adding a getClass() method onto JCCEnv
that invokes initializeClass inside a 'lock locked' block."
That will require the mutex to always be obtained, no? My patch only obtains
the mutex if the class has never been initialized by generating code that looks
like this:
jclass AbstractMap::initializeClass()
{
if (!class$)
{
lock$ locked;
if (!class$)
{
// We really do need to initialize it...
"I'm not sure I understand what you mean with the second patch you sent that
renames the lock type to lock$."
I found a case where a class being wrapped contained a function called "lock".
This caused the "lock" declaration in the classes .h file to override the lock
declaration in JCCEnv.h, causing the "lock locked;" statement to not compile.
I changed my patch to always post fix $ to every name used by the generated
code.
"Could you please attach the test your wrote so that I can verify that my
version of your patch still fixes the problem ?"
I am not using all of pylucene, but only using JCC to wrap the Eclipse BIRT
Report Runtime. My test involves using this wrapped Java library, so I don't
think it would be helpful to you. I am pretty sure if you put Greg's test in a
shell script that repeatedly calls it, it will fail fairly reliably.
> 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, 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
