Fix Crash in Multithread

[originell]

@tcalmant reported via mail that he found jpype crashing in multi-threading environments. I put this here because I think it's better to have it publicly in the bug tracker than in emails :)

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x000000010007168a, pid=828, tid=40963

JRE version: OpenJDK Runtime Environment (7.0-b01) (build 1.7.0-u40-unofficial-b1)
Java VM: OpenJDK 64-Bit Server VM (24.0-b50 mixed mode bsd-amd64 compressed oops)
Problematic frame:
C [Python+0x6e68a] subtype_dealloc+0xda

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

If you would like to submit a bug report, please include
instructions on how to reproduce the bug and visit:
http://icedtea.classpath.org/bugzilla
The crash happened outside the Java Virtual Machine in native code.
See problematic frame for where to report the bug.

He fixed it in one of his commits

Now we only need to test this with the changes from #17. Sadly I can't reproduce the error myself as it seems. So help is appreciated! :)

[tcalmant]

Just some details about my situation (with the Python 3 fork):
The bug occurred when running multithreaded applications with communications in both directions (Python <-> Java). The test/java_dom.py script also crashed for the same reason.
I reproduced the bug on Fedora 19 (64 bits) and on a Mac OS X 10.8, with both Oracle JDK and OpenJDK 7.

The bug was due to the destructor of JCleaner, the class that is used in JPype to clean up internal references, stored into PyCapsules (PyCObject in Python 2).
The release of those "capsules" must be done in a thread known by the GIL, between calls to PyGILState_Ensure() and PyGILState_Release().

I will try soon with the Python 2 version of jPype, maybe it's just a Python 3 evolution...

[originell]

Ah ok :) Btw thanks for your report and all the hard work :)!

[originell]

Hey @tcalmant are you still able to reproduce this with the latest commit? My tests still keep passing :S

[tcalmant]

Hey @originell !
I tried again on one of my "crashing" machines : it seems the bug was related to Python 3 and its new C-API to handle objects (PyCapsule, replacing PyCObject).
I'll try again on a second machine, just to be sure.

[originell]

Glad to hear that! Thank you for testing :)!

[originell]

Any output from your second machine @tcalmant ?

[tcalmant]

I've just finished my tests on a third machine, and the results are good.
This version of jPype works well on all machines, without modifications, where the previous version of jPype-py3 were crashing.

FYI, I'm running an OSGi framework (Apache Felix) with services shared between Java and Python, as a test.

Maybe we should open an issue on both our forks, in order to prepare a small set of test scripts in Python 2 and 3, in order ensure compatibility and detect this kind of derivation.
It could also be used as sample code for users of jPype.
What do you think ?

[originell]

Ah, have to read up on Felix :) Don't know much about OSGi frameworks.

Yeah that's a terrific idea to be honest :) Let's do this!

[zhihuizheng]

I met a similar problem, and it shows that

A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f48ea89d83b, pid=12678, tid=139951138658048
#
# JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b56 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libpthread.so.0+0x683b]  __pthread_init_static_tls+0x5b
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

I try code

if not jpype.isThreadAttachedToJVM():
    jpype.attachThreadToJVM()

but it doesn't work.

What does the problem really mean?