Open iversionpeng opened 1 year ago
Please try to use PointerScope: http://bytedeco.org/news/2018/07/17/bytedeco-as-distribution/
Hello, I would like to ask: Both Mat and MatVector inherit Pointer. There is DeallocatorReference in the Point object. This is to save the memory address. During use, GC occurs, causing the previously created Mat memory to be recycled. Later use of this mat will cause the program to crash. This design Is it reasonable?
Please try to set the "org.bytedeco.javacpp.nopointergc" system property to "true".
Please try to set the "org.bytedeco.javacpp.nopointergc" system property to "true".
We want to understand how javaCp manages off-heap memory so that we can use it more accurately. Can you provide some information for reference?
Please try to set the "org.bytedeco.javacpp.nopointergc" system property to "true".
It is true that there will be no crash when using this method; but why might there be a crash when closinging it? In single thread case
If you need reliability, please don't use GC, use PointerScope. It works just like C++, that's pretty much all you need to know.
If you need reliability, please don't use GC, use PointerScope. It works just like C++, that's pretty much all you need to know.
Thanks a lot!
It is the default way to release memory, Why is the GC method unreliable?
Because it's not designed to track anything else than heap memory.
Because it's not designed to track anything else than heap memory.
Sorry to have bothered you for so long. I try to understand what you mean.
MatVector contours = new MatVector();
Mat hierarchy = new Mat();
findContours(
securityErodeMat,
contours,
hierarchy,
RETR_CCOMP,
CHAIN_APPROX_SIMPLE
);
Mat[] mats = contours.get();
for (int i = 0; i < mats.length; ++i) {
Mat myMat = collect.get(i);
for (int y = 0; y < 800 * 1600; y++) {
Scalar currentColor = new Scalar(h, s, v, 0);
}
double area = contourArea(myMat, false);
}
When GC is triggered, the DeallocatorReference in MatVector may be recycled. When I use Mat later in contourArea, may I get the wrong data?
Yes, that's possible
Yes, that's possible Thanks a lot! Another question:
Where can I get its source code? Not by decompiling the case
You can ignore that library, it's not usually needed.
You can ignore that library, it's not usually needed.
I am verifying the unreliability of relying on Gc to recycle off-heap memory; through the code, I cannot infer what the problem is with relying on GC to recycle off-heap memory, but the phenomenon is that I am using the MatVector object, and then there is a GC log and a Collecting log. Immediately afterwards, the memory space in MatVector was cleared; the code to clean up the off-heap memory relies on GC to trigger MatVector recycling. MatVector is a strong reference and it should not be recycled when I use it, so I feel that it is not triggered by GC, maybe It is the clear method called elsewhere, so I would like to see its underlying implementation; I would like to hear your opinions.
So, what you probably want is the JNI code used for OpenCV and that gets generated at build time: https://github.com/bytedeco/javacpp-presets#build-instructions
question
How do we use these objects correctly?
maven
code
package com.debug2016.ocr.ofline;
import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import org.bytedeco.javacpp.indexer.Indexer; import org.bytedeco.opencv.opencv_core.*; import org.opencv.core.Core; import org.opencv.core.CvType;
import java.util.Arrays; import java.util.*; import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicInteger; import java.util.stream.Collectors;
import static org.bytedeco.opencv.global.opencv_core.; import static org.bytedeco.opencv.global.opencv_imgcodecs.imread; import static org.bytedeco.opencv.global.opencv_imgproc.; import static org.bytedeco.opencv.opencv_core.Mat.ones;
public class OriginLightCheck { private static Logger log = LogManager.getLogger();
public static void main(String[] strings) { String imagePath = strings[0]; Integer count = Integer.valueOf(strings[1]);
}
public static void securityCheck(Mat originMat, String sessionId) { log.info("securityCheck {} a originMat={},hash={},reference={}", sessionId, originMat, originMat.hashCode(), originMat.referenceCount());
}
private static Map<Scalar, Integer> checkLightNum(Mat extractedRegion, Mat myMat) {
// detectedColors.forEach(Pointer::deallocate); // colorMap.keySet().forEach(Pointer::close); log.info("checkLightNum end myMat={},hash={},myMatreference={},contoursHash={}", myMat, myMat.address(), myMat.referenceCount()); return colorMap; }
}
log
I am using a Mat object, but changes have occurred inside it, causing my program to crash? Why is it designed like this? How can I avoid this problem?
hs_error_pid.log
`SIGSEGV (0xb) at pc=0x0000000124db5edf, pid=5705, tid=0x0000000000001203 Stack: [0x000000030d836000,0x000000030d936000], sp=0x000000030d9354e0, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)