Threading issues in the SDK

[mrwonko]

I'm currently experiencing all kinds of strange issues. I'm trying to replicate problems I have with the Python binding of the SDK I'm working on. I'm linking the 32 bit sixense_s.lib and get crashes and deadlocks.

I once got a NULL-pointer error in USBManager::is_open() (line 93) (same crash as when you don't call sixenseInit) when trying to run this code:

sixenseInit();
sixenseExit();
sixenseInit();
sixenseIsBaseConnected(0);

But I cannot replicate that anymore. Instead, I now get an Access violation when caling sixenseExit() the second time, like this:

sixenseInit();
sixenseExit();
sixenseInit();
sixenseExit();

Call Stack:

 	HydraCrash1.exe!boost::thread::joinable()  + 0x31 bytes	C++
 	HydraCrash1.exe!USBManagerWin32::stop()  Line 141 + 0xb bytes	C++
 	HydraCrash1.exe!USBManager::stop()  Line 52	C++
 	HydraCrash1.exe!DriverMain::stop()  Line 432 + 0x5 bytes	C++
 	HydraCrash1.exe!sixenseExit()  Line 41	C++
>	HydraCrash1.exe!main(int argc, const char * * argv)  Line 13 + 0x5 bytes	C++

When actually using it, there's usually a delay between initialization and exitting. That leads to a deadlock though:

sixenseInit();
Sleep(1000);
sixenseExit();

This hangs with this call stack:

 	ntdll.dll!_ZwWaitForMultipleObjects@20()  + 0x15 bytes	
 	ntdll.dll!_ZwWaitForMultipleObjects@20()  + 0x15 bytes	
 	msvcr100.dll!__unlock_fhandle()  + 0x25 bytes	
 	kernel32.dll!_WaitForMultipleObjectsExImplementation@20()  + 0x8e bytes	
 	kernel32.dll!_WaitForMultipleObjects@16()  + 0x18 bytes	
 	HydraCrash1.exe!boost::this_thread::interruptible_wait()  + 0x1b8 bytes	C++
 	HydraCrash1.exe!boost::thread::join()  + 0x9a bytes	C++
 	HydraCrash1.exe!USBManagerWin32::stop()  Line 141	C++
 	HydraCrash1.exe!USBManager::stop()  Line 52	C++
 	HydraCrash1.exe!DriverMain::stop()  Line 432 + 0x5 bytes	C++
 	HydraCrash1.exe!sixenseExit()  Line 41	C++
>	HydraCrash1.exe!main(int argc, const char * * argv)  Line 11 + 0x5 bytes	C++

Also, I'd expect the initialization to actually be done by the time sixenseInit() returns - but it isn't until later that USBManagerWin32::check_devices gets called and connects the device, resulting in queries immediately after sixenseInit() to fail.