I am using Java JNI to integrate Z3 Solver C-Api in the framework that we are using.
Now, I am getting a segmentation fault with the following message –
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x664c4af0, pid=10878, tid=3060636480
#
# JRE version: 7.0_09-b30
# Java VM: OpenJDK Server VM (23.2-b09 mixed mode linux-x86 )
# Problematic frame:
# C [libSpdfZ3.so+0x634af0] small_object_allocator::allocate(unsigned int)+0x40
#
# 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:
# /home/rajtendulkar/workspace/Java-WorkSpace/spdf-compiler_with_Yices_and_Z3_StaticLib/hs_err_pid10878.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-7/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Inside the log file, it points to one call where context of Z3 is allocated. Basically it is an initialization routine with some memory allocation.
I want to try to understand what is the cause of this segmentation fault.
I would like to mention that my program works normally when run once. However if I run it in a for loop like this –
for (int i=0;i<5;i++)
{
// create z3 context
Z3Object obj = new Z3Object();
...
...
.. do some exploration here ..
...
...
...
}
I am just thinking if this has to do anything with memory allocation or insufficient memory or something like this?
Any pointers on how to debug this are appreciated.
EDIT :
When I sometimes try to debug the code and step through it slowly, I do not get this problem. Similarly, if I put a 5-second delay at the end of the for loop, I do not get any seg. fault. So can it be related with any concurrency issues?
It seems you are developing custom JNI bindings for Z3. Note that Z3 will come with it’s own bindings in one of the next releases. This is already included in the `unstable’ branch at Codeplex and may serve as inspiration or even as a replacement.
Note that objects obtained from the z3.dll must be reference-counted correctly, which can be quite tricky depending on the kind of garbage collector that is used. My first suspicion would be that an object gets collected (by Z3) without your program being aware of it (e.g., because reference counts get out of sync), or that your garbage collector is trying to destroy objects in an order that Z3 doesn’t anticipate (e.g., destroying contexts before all associated objects are destroyed).
The concurrency issues are perhaps not due to your own program, but because the garbage collector is concurrent (if I remember correctly, the later versions of Java actually come with 4 different ones and chose between them depending on the host system, which could be the source of the issue).