Maple often runs into SIGSEGV errors. This is due to bugs in Maple or at least bugs within the implementation of the OpenMaple API (which is native). Finally, I was able to find a case that actually produces the bug once I start the computation.
Obviously, we can/should inform Maplesoft about it but this gives me the opportunity to finally try to find ways to recover from that. Usually, this is impossible from our side. If Maple does not catch that bug and properly returns an exception, we are lost. SIGSEGV is pretty heavy, the damn entire VM crashes!
So the only way around would be to start a second VM just to communicate with Maple and in case of a SIGSEGV (or other signals different to 0) we can restart the VM.
This brings two problems:
[x] Start a VM from inside a VM (that might me more difficult that it look because we need to share all settings, variables, etc)
Maple often runs into SIGSEGV errors. This is due to bugs in Maple or at least bugs within the implementation of the OpenMaple API (which is native). Finally, I was able to find a case that actually produces the bug once I start the computation.
Obviously, we can/should inform Maplesoft about it but this gives me the opportunity to finally try to find ways to recover from that. Usually, this is impossible from our side. If Maple does not catch that bug and properly returns an exception, we are lost. SIGSEGV is pretty heavy, the damn entire VM crashes!
So the only way around would be to start a second VM just to communicate with Maple and in case of a SIGSEGV (or other signals different to 0) we can restart the VM.
This brings two problems:
At least for the second option, RMI (remote method invocation) looks like a promising option: https://www.baeldung.com/java-rmi
As our use case that cases the crash. Run our numeric evaluation with: