Is it correct to be explicitly freeing memory in this OpenXR LWJGL example

[Richtea]

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?

[spasi]

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.

[Richtea]

Yes, 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

Note 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)

[spasi]

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.

[Richtea]

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!