Remove pinned buffer list in JNI wrapper to avoid segmentation faults#697
Remove pinned buffer list in JNI wrapper to avoid segmentation faults#697MarkCallow merged 2 commits intoKhronosGroup:mainfrom ShukantPal:main
Conversation
interface/java_binding/src/test/java/org/khronos/ktx/test/KtxParallelTest.java
Outdated
Show resolved
Hide resolved
|
Thank you @ShukantPal. You are correct that |
|
@ShukantPal - first off, I just wanted to say many thanks again for looking into this problem. FYI - as a heads-up for you, I think there is still a related issue. I built the latest code (with your fix) on Windows/ARM and Windows/x64 and when I take my multithreaded test from issue #690 and increase the number of iterations, then it looks like it's leaking memory. (This can be seen from Windows Task Manager). The test eventually crashes the JVM on both platforms, where it should run OK forever, Note that this is not normal Java Heap memory variation, as if I limit that with e.g. the JVM flag -Xmx512m, then it still fails with a JVM crash. even consuming all the main memory and swap on my Windows/x64 box, which has 128GB RAM and 128GB swap. I'm not confident in my own build of toktx (not sure I specified all the right build options), so I'm wont raise a bug at this stage, but I will do if the problem persists when I get an official 4.1.1 (or whatever) toktx build with your fix. Thanks again |
…KhronosGroup#697) * Remove pinned buffer list in JNI wrapper to avoid segmentation faults * Update interface/java_binding/src/test/java/org/khronos/ktx/test/KtxParallelTest.java
3 participants
Fixes #690
After going through the C++ code in libktx, I realized that ktxTexture{1,2}_setImageFromMemory copy from the source buffers anyway. That meant pinning the source byte arrays in Java didn't do anything useful; hence, I removed that and the associated code keeping track of pinned buffers.
I have also added a unit test to make sure the JNI wrapper is stable for ~1000 iterations of usage.