Open goomba-inside opened 1 year ago
I had the same problem
Anyone found a solution? Experiencing same issues
Unfortunately I have no insight into this problem. I would search the archives. It must be some mismatch between the assumptions of the JVM and Python.
It seems that on Apple Silicon Macs any exception on the Java side leads to a SIGBUS crash.
Here a short example:
import jpype
import jpype.imports
jpype.startJVM()
from java.lang.System import out
out.println("Huhu!")
out.println(1) # This line is deliberately passing an unexpected parameter in order to provoke an exception.
Output (with openjdk@8 - the same happens with e.g. openjdk@21, the only difference is that the VM warning isn't shown in that case):
OpenJDK 64-Bit Server VM warning: Attempt to protect stack guard pages failed.
OpenJDK 64-Bit Server VM warning: Attempt to deallocate stack guard pages failed.
Huhu!
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0xa) at pc=0x000000019065aa58, pid=18998, tid=0x0000000000000103
#
# JRE version: OpenJDK Runtime Environment (Zulu 8.68.0.21-CA-macos-aarch64) (8.0_362-b09) (build 1.8.0_362-b09)
# Java VM: OpenJDK 64-Bit Server VM (25.362-b09 mixed mode bsd-aarch64 compressed oops)
# Problematic frame:
# C [libunwind.dylib+0xaa58] _Unwind_GetIP+0xe0
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# [some path]/hs_err_pid18998.log
#
# If you would like to submit a bug report, please visit:
# http://www.azul.com/support/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
zsh: abort
This makes debugging a chore. One workaround is to create Java-side wrapper code for everything. E.g.:
public class MyClassPyWrapper {
private MyClass myClass;
private MyClassPyWrapper() {}
public static MyClassPyWrapper create(string aPar) {
try {
myClass = new MyClass(aPar);
return this;
} catch(Exception e) {
e.printStackTrace(); // if an exception is thrown during construction of MyClass it is now printed to stdout. Similar wrapper methods can be created for the other methods of MyClass
return null;
}
}
...
}
This is of course tedious, optimally one could write Python code without having to create wrappers.
Unfortunately I do not have access to that machine. There is no reason for a sigbus to be happening unless the code was not compiled with exception support. We take Java exceptions and make them C++ exceptions. There is a master try block on every piece of code to ensure it can’t segfault when it gets to Python C layer.
Github seems to offer Apple Silicon macos runners to open source projects for free now: https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/
I had this same issue with the Python 3.9 that was bundled with Xcode. I installed the official Python 3.12 release and the issue went away.
Can still reproduce the issue with Python 3.12.2 and the current jpype build from main. The problem still occurs highly sporadic, the probability seems to go up with system load (so could be some kind of race condition). The error message is slightly different this time:
An irrecoverable stack overflow has occurred.
#
#
#
#
#
#
#
jpype.startJVM()
crashes withA fatal error has been detected by the Java Runtime Environment
I also tried to build and test jpype but the first test seemed to abort without printing error message (The second code block contains the output).
I would appreciate any tips for debugging!
startJVM() crash:
JPype build log and test failure: