In my own application I'm using LWJGL to bind to OpenXR. I originally following this example to create my application
https://github.com/knokko/lwjgl3/blob/origin/fix-xr-gl-sample/modules/samples/src/test/java/org/lwjgl/demo/openxr/HelloOpenXRGL.java
My application works well on my machine, and well on an end users machine except that it hard crashes on exit
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f36a18dacc0, pid=94325, tid=94345
#
# JRE version: OpenJDK Runtime Environment (17.0.7+7) (build 17.0.7+7-Debian-1deb11u1)
# Java VM: OpenJDK 64-Bit Server VM (17.0.7+7-Debian-1deb11u1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C [libc.so.6+0xa3cc0]
I've historically got those sorts of things when I've explicitly called free() on objects created like `XrSessionActionSetsAttachInfo.create();`. I never call free on these objects and (hopefully correctly?) believe that these are automatically freed by LWJGL.
Which brings me to the application exiting and the example. The only frees I have in my example are on application shutdown and I include them because the HelloOpenXRGL example does
helloOpenXR.eventDataBuffer.free();
helloOpenXR.views.free();
helloOpenXR.viewConfigs.free();
for (Swapchain swapchain : helloOpenXR.swapchains) {
xrDestroySwapchain(swapchain.handle);
swapchain.images.free();
}
I think the first 3 frees are correct (as the memory was originally allocated with `calloc`)
But the swap chain images are created with a `create`
XrSwapchainImageOpenGLKHR.Buffer swapchainImageBuffer = XrUtils.fill(
XrSwapchainImageOpenGLKHR.create(imageCount),
XrSwapchainImageOpenGLKHR.TYPE,
KHROpenGLEnable.XR_TYPE_SWAPCHAIN_IMAGE_OPENGL_KHR
);
Would I be correct in saying if it's created with a `create` it is managed memory and shouldn't be manually freed?
Hey Richtea,
Yes, that is correct. Memory allocated with .create(), that delegates to BufferUtils -> ByteBuffer.allocateDirect, should not be freed explicitly. Note that the LWJGL demo uses calloc for swapchainImageBuffer.
For memory allocation troubleshooting, you may run the application with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugAllocator=true. It will report issues like freeing of GC-managed memory, double-freeing, memory leaks on process exit.
QuoteYes, that is correct. Memory allocated with .create(), that delegates to BufferUtils -> ByteBuffer.allocateDirect, should not be freed explicitly.
Thanks, I'm glad my understanding is correct
QuoteNote that the LWJGL demo uses calloc for swapchainImageBuffer.
Does it? I was looking at https://github.com/knokko/lwjgl3/blob/origin/fix-xr-gl-sample/modules/samples/src/test/java/org/lwjgl/demo/openxr/HelloOpenXRGL.java#L452 where it seems to be created. Is that the right demo I'm looking at? (Its so hard with github repos to know which is the official one)
I was referring to the same demo that was contributed to LWJGL, here: https://github.com/LWJGL/lwjgl3/blob/master/modules/samples/src/test/java/org/lwjgl/demo/openxr/HelloOpenXRGL.java. It's slightly different, not sure which version is more recent.
Ha, and in that version there is a memory bug fix https://github.com/LWJGL/lwjgl3/commit/9a997a2143e565b83a9bf760e57fcb141856c413 changing the create to a calloc.
So that all makes sense then, I've just been looking at an old version of that demo. Thanks!