-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGSEGV on termination #842
Comments
Thanks for the report. I will look into this as soon as my IT folks get my development machine repaired. What is the value of “isJVMStarted()”? Does adding an if statement for it (in Python or in pyjp_module) fix the issue?
|
First, I have noticed that the SIGSEGV is not easy to reproduce, happening as rarely as perhaps 1 time in 200. Second, I've added a print() of “isJVMStarted()”, and not seen the failure after a handful of runs. Will report back after gathering more data. |
OK, it failed just now even with the “isJVMStarted()” in place on my Ubuntu setup:
Again, it must have run without issue several hundred times before this point. Interestingly, my MacOS-based colleage is regularly seeing what we think is the same issue, and he was able to extract a crash log: hs_err_pid53983.log. This repro is from the cycling of Celery workers, with the SIGSEGV at process exit (or at least we assume so, since it has no discernible effect on the operation of the system). Note: he does not have the inserted isJVMStarted(). |
And here is a curious thing...I just ran myusual test script, and it seemed to exit twice, like this:
So, _JTerminate() was called twice, and once thought the JVM started, and once not. |
Any chance you can get this to replicate on a reduced version of the code? It sill seems like something in the JVM is crashing. So either we are creating the JVM twice as a result of a fork or a terminate and restart. The guard code is supposed to prevent starting twice, but perhaps if you can replicate a miss and fix it we can finally resolve this.
|
I tried before, but there is a lot of stuff, and when I trimmed too far it stopped failing. Now that we have a slightly different problem, I'll try once again. I'll report back with any results. |
What are the ramifications of doing? def _JTerminate():
try:
if _jpype.isStarted():
_jpype.shutdown()
except RuntimeError:
pass |
It should make sure that Java closes properly when Python exits. Before we did not guarantee that Java files were properly closed nor that Java threads had terminated. If you call shutdown manually then isStarted will be false and it will just operate as normal. If Python exits without closing Java we perform the Java shutdown first. If there are non-daemon threads then it will wait for them to terminate.
|
Based on my experiment adding calls to
|
Can you look over #937 to see if an option fixes this issue? |
Hi. I am using JPype 1.2.0 and have been seeing this issue for a while. The Jenkins build or local run has intermittent failures with below failure. Any suggestion to resolve this issue is appreciated:
|
Could it be related to what you wrote here in your documenation? https://jpype.readthedocs.io/en/latest/userguide.html#errors-reported-by-python-fault-handler |
It seems like using the |
This may help avoid the random segfaults, according to jpype-project/jpype#842 (comment)
As per #720, to get 1.0.2 working for us, I moved JPype initialisation to be delayed it until actually needed. On process exit, it seems that if the initialisation code is not actually called, the process exists with a SIGSEGV:
And here is line 321:
The only reference to jpype that this program could have made is an import as part of its transitive fanout:
and it won't have invoked startJVM().
The text was updated successfully, but these errors were encountered: