In BestPracticesLayerXrSyncActions, there is a call to g_framesInFlight.empty() without g_frameMutex being locked. If g_framesInFlight wasn't empty at the time, g_frameMutex is then locked and g_framesInFlight.front() is used. The use of g_framesInFlight before the mutex is locked allows a data race. g_framesInFlight could have been emptied by a call to xrEndFrame on another thread before the mutex is locked by the thread calling xrSyncActions. This can cause address sanitizer to diagnose a container overflow, since front requires an element and there may no longer be one.
If my understanding of the OpenXR spec is correct, external synchronization is required for the session parameter of xrEndFrame only with respect to other calls to xrEndFrame, xrBeginFrame or xrDestroySession, and it appears permissible to call other functions such as xrWaitFrame or xrSyncActions on another thread at the same time as xrEndFrame despite passing the same XrSession.
In
BestPracticesLayerXrSyncActions, there is a call tog_framesInFlight.empty()withoutg_frameMutexbeing locked. Ifg_framesInFlightwasn't empty at the time,g_frameMutexis then locked andg_framesInFlight.front()is used. The use ofg_framesInFlightbefore the mutex is locked allows a data race.g_framesInFlightcould have been emptied by a call toxrEndFrameon another thread before the mutex is locked by the thread callingxrSyncActions. This can cause address sanitizer to diagnose a container overflow, sincefrontrequires an element and there may no longer be one.If my understanding of the OpenXR spec is correct, external synchronization is required for the
sessionparameter ofxrEndFrameonly with respect to other calls toxrEndFrame,xrBeginFrameorxrDestroySession, and it appears permissible to call other functions such asxrWaitFrameorxrSyncActionson another thread at the same time asxrEndFramedespite passing the sameXrSession.