BestPracticesLayerXrBeginFrame makes a reference named currentFrameState to the front item of std::deque g_framesInFlight ,
|
FrameState ¤tFrameState = g_framesInFlight.front(); |
then, under some conditions, it pops the front item off of the g_framesInFlight, invalidating this reference
|
g_framesInFlight.pop_front(); |
|
g_framesInFlight.pop_front(); |
This reference is used after being invalidated. For example, the erased element is used as the destination of an assignment in the line after both calls to pop_front:
|
if (g_framesInFlight.size() > 0) currentFrameState = g_framesInFlight.front(); |
|
if (g_framesInFlight.size() > 0) currentFrameState = g_framesInFlight.front(); |
Perhaps these was intended to reseat the reference to refer to the new front item, but this is not possible with a C++ reference.
This occurs when skipping calling xrEndFrame for an unwanted frame, which might not be best practice, but is explicitly permitted by the OpenXR specification:
An application may call xrBeginFrame again if the prior xrEndFrame fails or if the application wishes to discard an in-progress
frame. A successful call to xrBeginFrame again with no intervening xrEndFrame call must result in the success code XR_FRAME_DISCARDED being returned from xrBeginFrame. In this case it is assumed that the xrBeginFrame refers to the next frame and the previously begun frame is forfeited by the application.
Therefore I believe the undefined behaviour is not justified in this case.
BestPracticesLayerXrBeginFramemakes a reference namedcurrentFrameStateto the front item ofstd::dequeg_framesInFlight,OpenXR-SDK-Source/src/api_layers/best_practices/best_practices_validation.cpp
Line 151 in 21714cf
then, under some conditions, it pops the front item off of the
g_framesInFlight, invalidating this referenceOpenXR-SDK-Source/src/api_layers/best_practices/best_practices_validation.cpp
Line 159 in 21714cf
OpenXR-SDK-Source/src/api_layers/best_practices/best_practices_validation.cpp
Line 172 in 21714cf
This reference is used after being invalidated. For example, the erased element is used as the destination of an assignment in the line after both calls to
pop_front:OpenXR-SDK-Source/src/api_layers/best_practices/best_practices_validation.cpp
Line 160 in 21714cf
OpenXR-SDK-Source/src/api_layers/best_practices/best_practices_validation.cpp
Line 173 in 21714cf
Perhaps these was intended to reseat the reference to refer to the new front item, but this is not possible with a C++ reference.
This occurs when skipping calling
xrEndFramefor an unwanted frame, which might not be best practice, but is explicitly permitted by the OpenXR specification:Therefore I believe the undefined behaviour is not justified in this case.