It seems that something has changed just in the past few days (as of 2018-08-23) that's causing our application to crash on exit.
We wrap the OculusSDK 1.8.0 in our own DLL that we load at run-time via LoadLibrary, depending on application configuration options. (The application supports various VR tracking and display environments; the Oculus Rift is one option.)
As of today, the application crashes on exit, only if the OculusSDK has been opened, and only in the release build; the debug build does not crash. This happens whether or not we explicitly call FreeLibrary for our DLL at program exit.
The OculusSDK logs these status messages in our console window:
[ At startup, we open with ovr_Initialize (nullptr) ]
23/08 19:07:20.832 {INFO} [Kernel:Default] [CAPI] LibOVR module is located at C:\Program Files\Oculus\Support\oculus-runtime\LibOVRRT64_1.dll 23/08 19:07:20.835 {INFO} [Client] Connected to the server running version (prod = 1).1.29.0(build = 651191) feature version = 0. Client runs version (prod = 1).1.29.0(build = 0) feature version = 0 23/08 19:07:20.838 {DEBUG} [Kernel:Default] [HMDState] Using default profile default 23/08 19:07:20.838 {INFO} [Kernel:Default] IAD changed to 64.2mm 23/08 19:07:20.839 {DEBUG} [SharedMemory] Creating factory 23/08 19:07:22.178 {DEBUG} [D3D11_CliCompositorClient] CliD3D11CompositorClient::initialize 1 23/08 19:07:22.220 {DEBUG} [KMTSyncObject] Creating KMTHandle 0x0d2fc4d0 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] Creating KMTHandle 0x0d2fc610 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] KMTHandle::Create hDevice=0x80000380 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] KMTHandle::Create hContexts[0] = 2147485504 23/08 19:07:22.222 {DEBUG} [KMTSyncObject] KMTHandle::Create hContexts[1] = 2147485824 23/08 19:07:22.286 {DEBUG} [D3D11_CliCompositorClient] CliD3D11CompositorClient::addGLRef 2 23/08 19:07:23.552 {INFO} [Kernel:Default] [HMDState] Detected the active window handle changed to 111af0ll 23/08 19:07:28.635 {WARNING} [Tracking:Filter] Prediction interval too high: 0.101367 s, clamping at 0.100000 s
[ The application runs well, with a good frame rate. I can move and resize the on-screen mirror window. Everything renders well in the Rift and on-screen. The test scene averages well over 100 frames per second, so the initial high prediction interval seems to be a startup fluke. ]
[ At exit, we close with ovr_Destroy (m_Session) and ovr_Shutdown() ]
At program exit, it dies in the Windows function __tmainCRTStartup(void) (in crtexe.c):
A problem caused the program to stop working correctly.
All of our C++ wrapper class close and d'tor functions appear to return successfully.
I have wrapped the entire body of our main function in try {} catch() {}, but it fails to catch this exception. I have put a 10-second sleep just before the program exit, but that merely delays the crash; it does not avoid it.
The console messages and the crash are all new behavior that I did not see (or notice) just a few days ago. The crash is definitely a new behavior. This application has not changed during that time. Judging from those console messages, it seems that maybe some Oculus resource isn't shutting down properly -- and that maybe somebody has been struggling with that.
The fact that it crashes in the release build, but not the debug build, suggests that maybe something has not been initialized properly (e.g., to zero). Maybe the debug build initializes it; or maybe the lower degree of optimization avoids some memory corruption. Maybe there's a dangling reference to SharedMemory. Maybe the logging itself is causing the crash. I did not request logging, and in fact tried to explicitly disable it with
but the logging messages still appear in the console window. The appearance of the logging messages correlates with the crash-at-exit behavior: they're both new.
More information: Sorry to say that the problem has not vanished. It's merely inconsistent, but the application still usually crashes on exit.
I notice in the Task Manager that the application seems to be leaking memory when I'm not wearing the HMD. The memory is stable while I'm wearing it, grows steadily while I'm not wearing it, and never goes down again until program exit.
ovr_SubmitFrame(...) always returns ovrSuccess whether I'm wearing the HMD or not. It never returns ovrSuccess_NotVisible or any other non-zero status. So, I have no way of knowing whether the user is actually wearing the HMD. In any case, I don't see why it should be growing memory regardless of the success or failure of ovr_SubmitFrame.
I want to reiterate that this crash is new behavior. This code had been running fine for several years until just a few days ago. I see that most of the stuff in \Program Files\Oculus\Support\ was updated on 08/07/2018. I've only encountered these crashes in the past week, but maybe I didn't use the Oculus during the preceding week.
30/08 14:28:37.251 {INFO} [Kernel:Default] [CAPI] LibOVR module is located at C:\Program Files\Oculus\Support\oculus-runtime\LibOVRRT64_1.dll
30/08 14:28:37.253 {INFO} [Client] Connected to the server running version (prod = 1).1.29.0(build = 651191) feature version = 0. Client runs version (prod = 1).1.29.0(build = 0) feature version = 0
30/08 14:28:37.310 {DEBUG} [Kernel:Default] [HMDState] Using default profile default
30/08 14:28:37.310 {INFO} [Kernel:Default] IAD changed to 64.3mm
Our PC SDK team is requesting log files from when this behavior occurs or a copy of your project for diagnosing this issue. Let me know if this is possible and please use a dropbox link and private message me.
Thank you very much for your reply.
I'm not sure what log files you're referring to:
* If I ovr_Initialize (nullptr), the log messages appear in STDOUT, which for us is a CMD window. I pasted all of them into my original message above -- I didn't omit any.
* On the other hand, if I ovr_Initialize (&init_params), where init_params = { (ovrInit_Debug | ovrInit_RequestVersion), OVR_MINOR_VERSION, myLogCallback, 0, 0 }, then I actually get a few less messages in the log file. In particular, the last few messages from Kernel System, SharedMemory, and Kernel Default, that appear in the default case above, do not appear in the log file:
Messages missing from the log file, compared to the default log-to-STDOUT, from destructors at program exit: