You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When terminating a Godot application which uses any OpenXRExtensionWrapperExtension objects, the application terminates in a call of memdelete(extension_wrapper) with a pointer that isn't a valid block of heap memory.
The problem is caused by the inheritance structure of OpenXRExtensionWrapperExtension:
The problem occurs when OpenXRExtensionWrapperExtension::register_extension_wrapper() registers this class with OpenXRAPI::register_extension_wrapper()AS AN OpenXRExtensionWrapper:
When the OpenXRExtensionWrapperExtension::register_extension_wrapper() registers itself, it has to cast its this pointer to an OpenXRExtensionWrapper* which involves adding 408 to the pointer value to jump over the Object. When memdelete() is called on this pointer, it fails because the pointer isn't a block of allocated memory.
This pattern is fully supported in C++ using the normal new/delete, as the compiler will generate a "virtual deleting destructor" in the objects VTABLE, so a delete by any class type will correctly call the real destructor, then adjust the pointer to the start of the object and delete the memory.
Godot's use of memdelete() appears to bypass this machinery preventing safe deletion of multiple-inheritance classes.
Steps to reproduce
Run Godot with the godot_openxr_vendors extension (or any extension providing OpenXR extensions) and then terminate the application.
Minimal reproduction project (MRP)
N/A
The text was updated successfully, but these errors were encountered:
I just posted PR #88688 which provides a way to fix memdelete() in this case. However, I don't know if a general solution that modifies core for such an uncommon pattern is really the right way to go... :-/
I'm going to make an alternative PR that just fixes this for OpenXRExtensionWrapper, in case that doesn't turn out to be popular.
Tested versions
System information
Windows 11, gl_compatibility, NVidia RTX 3070 TI
Issue description
When terminating a Godot application which uses any OpenXRExtensionWrapperExtension objects, the application terminates in a call of
memdelete(extension_wrapper)
with a pointer that isn't a valid block of heap memory.The problem is caused by the inheritance structure of OpenXRExtensionWrapperExtension:
godot/modules/openxr/extensions/openxr_extension_wrapper_extension.h
Line 42 in 652438a
The problem occurs when
OpenXRExtensionWrapperExtension::register_extension_wrapper()
registers this class withOpenXRAPI::register_extension_wrapper()
AS AN OpenXRExtensionWrapper:godot/modules/openxr/extensions/openxr_extension_wrapper_extension.cpp
Lines 233 to 235 in 652438a
The OpenXRAPI extension wrappers saves OpenXRExtensionWrapper instances in a
Vector<OpenXRExtensionWrapper *>
and later deletes them usingmemdelete
.The problem is that the memory layout of OpenXRExtensionWrapperExtension is as follows (sizes specific to Windows/X64):
When the
OpenXRExtensionWrapperExtension::register_extension_wrapper()
registers itself, it has to cast itsthis
pointer to anOpenXRExtensionWrapper*
which involves adding 408 to the pointer value to jump over theObject
. Whenmemdelete()
is called on this pointer, it fails because the pointer isn't a block of allocated memory.This pattern is fully supported in C++ using the normal new/delete, as the compiler will generate a "virtual deleting destructor" in the objects VTABLE, so a delete by any class type will correctly call the real destructor, then adjust the pointer to the start of the object and delete the memory.
Godot's use of memdelete() appears to bypass this machinery preventing safe deletion of multiple-inheritance classes.
Steps to reproduce
Run Godot with the godot_openxr_vendors extension (or any extension providing OpenXR extensions) and then terminate the application.
Minimal reproduction project (MRP)
N/A
The text was updated successfully, but these errors were encountered: