Ask Your Question

Java Runtime crashes on concurrent Garbage Collection

asked 2016-03-12 10:09:42 -0500

icePatronus gravatar image

updated 2016-03-15 06:42:35 -0500


I'm using OpenCV 3.1 in Java under xubuntu 14.10 to match the camera input with a given image database using the FlannBased DescriptorMatcher (Descriptors precomputed with SURF). The code works perfectly with good results, but after some time (ranging from 10sec to 5min) my JRE crashes with different errors dealing with memory access/allocation, mostly [1] and [2].

Simplified version of my Code:

Thread 1:
       while(running) {
               synchronized (cameraImage) {
     ; //some selfwritten imshow function (swing JFrame)

Thread 2:
       while(running) {
              synchronized (cameraImage) {
              surfDescriptorExtractor.detectAndCompute(matchImage, descriptors);
              flannMatcher.match(descriptor, matches);
              return bestMatch(matches);

My assumptions:

At first I thought it would be a problem of concurrent access of the camImage, but I have completly synchronized the copy parts.
It does not crash (only tested for ~30min), if I run both parts in one thread or if I do not update the JFrame.

I executed the jar with -verbose:gc option and noticed, that Garbage Collection (gc) is called quite frequently (~every 3sec, depending on JRE's -Xmx memory size) and that every error is directly after a gc. If I do not update the JFrame the gc is called almost never.

So here is my assumption: Thread 1 updates the Swing GUI and creates some Java Objects (mainly a BufferedImage of the Mat), invokes the GC as there is not enough space, and GC crashes the nativly allocated memory on which Thread 2 is currently working on.

One work around which did not crash yet is, that I manually call the GC in Thread 2 before calling any OpenCV methods to hope that it is not called again during those methods.

Thanks in advance for any help!
It would be nice to have a solution that really is safe and still works with two threads.


# A fatal error has been detected by the Java Runtime Environment:
#  SIGSEGV (0xb) at pc=0x00007f182db1b7e3, pid=28910, tid=139740120311552
# JRE version: Java(TM) SE Runtime Environment (8.0_40-b25) (build 1.8.0_40-b25)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.40-b25 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  []
[2] *** Error in `java': malloc(): memory corruption: 0x00007efdfc01f780 ***


I have broken down my code into the essential part. If I compile the following code with

javac -classpath /path/to/opencv-310.jar
and run
java -Djava.library.path=/path/to/lib -cp .:/path/to/opencv-310.jar Main
it crashes within the first two minutes.
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.Random;
import org.opencv.core.Core;
import org.opencv.core.CvType;
import org.opencv.core.DMatch;
import org.opencv.core.Mat;
import org.opencv.core.MatOfDMatch;
import org.opencv.core.MatOfKeyPoint;
import org.opencv.features2d.DescriptorExtractor;
import org.opencv.features2d.DescriptorMatcher;
import org.opencv.features2d.FeatureDetector;
import org.opencv.videoio.VideoCapture;

public class Main {

    private static final Mat cameraMat;

    static {
        System.loadLibrary ...
edit retag flag offensive close merge delete


"but I have completly synchronized the copy parts." -- please show us.

berak gravatar imageberak ( 2016-03-12 10:27:27 -0500 )edit

Edited the code. As far as I understand Java's synchronization, this means that it locks the cameraImage object (that is final btw) for one thread while this Mat is modified/copied. After that both threads run on different copies of the image.

icePatronus gravatar imageicePatronus ( 2016-03-12 10:51:39 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2017-06-08 02:44:36 -0500

nicolbiden gravatar image

More on....Memory Management in Java


edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower


Asked: 2016-03-12 10:09:42 -0500

Seen: 297 times

Last updated: Jun 08 '17