Shutdown properly

[Greg Aring]

When Unity stops playing, DirectMode just keeps on running. Need to stop the plugin and remove callbacks when Unity shuts down.

[Greg Aring]

With DirectMode off, Windows keep stacking up. With DirectMode on, 2nd time running causes a crash.

[Russell Taylor]

This should be taken care of by deleting the RenderManager. Be careful if you forget this, I've had BSODs when I unplug and replug the monitor after a crash exit from the program. That's why the example programs all have a ^C handler registered on Windows...

[Greg Aring]

Calling "delete render" here, but I'm not sure when Unity fires this event (I think when Unity editor or build closes, but not when a scene stops):
https://github.com/OSVR/OSVR-Unity-Rendering/blob/unity5_2_update/OsvrRenderingPlugin.cpp#L877

but I've also tried putting it here:
https://github.com/OSVR/OSVR-Unity-Rendering/blob/unity5_2_update/OsvrRenderingPlugin.cpp#L345

which is called from Unity when the scene stops:
https://github.com/sensics/OSVR-Unity-RenderManagerBranch/blob/clienkit_RenderMan_Unity5_2/OSVR-Unity/Assets/OSVRUnity/src/DisplayController.cs#L117

but this causes a Windows alert to pop up with "the application terminated in an unusual way" .
Log shows that after stopping then pressing play again, the crash occurs after the 2nd eye is rendered:
https://gist.github.com/DuFF14/6c38ac910cc810e4de0b#file-editor-log-L5118

and the stack trace shows the last call was D3DPerformance_SetMarker:
https://gist.github.com/DuFF14/6c38ac910cc810e4de0b#file-editor-log-L5249

[Russell Taylor]

Are you rendering in one thread and calling delete() in another? Having the object destroyed while another thread is still calling its functions could be a problem.

I have not tried to make RenderManager thread-safe. If we end up doing ATW in the sense of repeating the last geometry every frame until we get a new one (shifting each time and making sure we hit vertical retrace), then it will have to be internally threaded, but for now it has been easier to think of it as a single thread.

[Greg Aring]

I defined a shutdown event and I'm passing that via GL.IssuePluginEvent, which should sync with the rendering thread. Looks like It's getting farther than before, but still crashing in RenderManager deconstructor:

========== OUTPUTING STACK TRACE ==================

0x75834598 (KERNELBASE) RaiseException
0x62D79339 (MSVCR120) CxxThrowException
0x52FE1C8B (osvrRenderManager) osvr::renderkit::RenderManager::~RenderManager
0x52FEF239 (osvrRenderManager) OSVRRenderManagerConfiguration::print
0x52FEF25B (osvrRenderManager) OSVRRenderManagerConfiguration::print
0x6575196D (OsvrRenderingPlugin) [c:\users\greg\documents\osvr\osvr-unity-rendering\osvrrenderingplugin.cpp:365] Shutdown
0x00317504 (unity_directmode1) GetGfxDevice
0x007A215E (unity_directmode1) RemapPPtrTransfer::TransferTypelessData
0x007A4E8E (unity_directmode1) RemapPPtrTransfer::TransferTypelessData
0x0042193D (unity_directmode1) Thread::RunThreadWrapper
0x75627C04 (KERNEL32) BaseThreadInitThunk
0x7756AD1F (ntdll) RtlInitializeExceptionChain
0x7756ACEA (ntdll) RtlInitializeExceptionChain

========== END OF STACKTRACE ===========

[Russell Taylor]

I know that the ^C event in Windows happens in a different thread from the main application. Perhaps these other events are as well. I handle this in the example programs using a boolean that gets set to true in the handler and the main loop notices that it has become true and shuts itself down. A semaphore would be even better, perhaps, but we're not terribly worried about the race in this case.

[Greg Aring]

Finally tracked this down to the LinkDebug function which links c++ debug log output to the Unity console. Disabling this feature for Release builds allows a clean start, stop, and exit in Unity editor or executable.