Commit: bcc8f7c6be60c78f8351874880ab139d3a3410ad
Author: Julian Eisel
Date: Wed Aug 7 22:17:55 2019 +0200
Branches: soc-2019-openxr
https://developer.blender.org/rBbcc8f7c6be60c78f8351874880ab139d3a3410ad
Fix xrDestroy calls to data already implicitly destroyed by OpenXR
Would effectifely result in null-ops, since the loader does good sanity
checks. The failing functions would still lead to error prints though.
===================================================================
M intern/ghost/intern/GHOST_XrContext.cpp
===================================================================
diff --git a/intern/ghost/intern/GHOST_XrContext.cpp
b/intern/ghost/intern/GHOST_XrContext.cpp
index 8edbd625f3a..7fbcb30196b 100644
--- a/intern/ghost/intern/GHOST_XrContext.cpp
+++ b/intern/ghost/intern/GHOST_XrContext.cpp
@@ -67,6 +67,10 @@ GHOST_XrContext::~GHOST_XrContext()
{
// TODO OpenXR calls here can fail, but we should not throw an exception in
the destructor.
+ /* Destroy session data first. Otherwise xrDestroyInstance will implicitly
do it, before the
+ * session had a chance to do so explicitly. */
+ m_session = nullptr;
+
if (m_oxr->debug_messenger != XR_NULL_HANDLE) {
assert(m_oxr->s_xrDestroyDebugUtilsMessengerEXT_fn != nullptr);
m_oxr->s_xrDestroyDebugUtilsMessengerEXT_fn(m_oxr->debug_messenger);
_______________________________________________
Bf-blender-cvs mailing list
Bf-blender-cvs@blender.org
https://lists.blender.org/mailman/listinfo/bf-blender-cvs
