OculusSDK causing application crash on exit

[twhall]

Windows 10, Visual Studio 2010 C++

OculusSDK 1.8.0, firmware version 7.9

GeForce GTX 1070/PCIe/SSE2, OpenGL Version: 4.6.0 NVIDIA 398.11, GLSL Version: 4.60 NVIDIA

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() ]

23/08 19:07:31.115 {DEBUG}   [D3D11_CliCompositorClient] CliD3D11CompositorClient::release 2
23/08 19:07:31.117 {DEBUG}   [D3D11_CliCompositorClient] CliD3D11CompositorClient::release 1
23/08 19:07:31.117 {DEBUG}   [D3D11_CliCompositorClient] Unblocking monitored fence
23/08 19:07:31.121 {INFO}    [Kernel:System] Graceful shutdown: OnThreadDestroy
23/08 19:07:31.121 {INFO}    [Kernel:System] Graceful shutdown: OnSystemDestroy
23/08 19:07:31.121 {DEBUG}   [SharedMemory] Destroying factory
23/08 19:07:31.121 {DEBUG}   [Kernel:Default] [Client] Disconnected
23/08 19:07:31.121 {INFO}    [Kernel:System] Graceful shutdown: Stopping logger

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

   ovrInitParams init_params = { 0, 0, nullptr, 0, 0 };
   ovr_Initialize (&init_params)

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.

Please advise.  Thanks.

--

Ted Hall <twhall@umich.edu>

[twhall · Accepted solution]

Update:

*  I quit and restarted the Oculus app, but that made no difference.

*  I shut down and rebooted the computer, and the crash problem vanished.  Something else must have corrupted the system somehow.

Sorry for the noise.  I would like to un-accept this answer ...

[twhall]

P.S.:  I have no idea why "NerveGear" appears in the banner.  I've never heard of it.

[twhall]

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.

[gia_len]

I have the same problem:

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

30/08 14:28:37.310 {DEBUG}   [SharedMemory] Creating factory

[twhall]

@imperativity

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:

    23/08 19:07:31.121 {INFO}    [Kernel:System] Graceful shutdown: OnThreadDestroy

    23/08 19:07:31.121 {INFO}    [Kernel:System] Graceful shutdown: OnSystemDestroy

    23/08 19:07:31.121 {DEBUG}   [SharedMemory] Destroying factory

    23/08 19:07:31.121 {DEBUG}   [Kernel:Default] [Client] Disconnected

    23/08 19:07:31.121 {INFO}    [Kernel:System] Graceful shutdown: Stopping logger

It's a very large C++ VR project.  I'm trying to narrow it down before copying it to you for diagnosing.