Game (unity3d) with phidgets hangs on close

[burley]

Can we trouble you for an example of best practise, code flow?

For example here:
https://phidgetseducation.edunext.io/co ... d11b6a85a7

Doesn't seem to show proper clean up on app exit. So I followed that as an example to connect to and register events for the RFID Reader.

Cheers.

That code doesn't have any exit handling stuff at all. I have been fiddling around with Unity a bit today and I personally handled it like this:

Code: Select all

	void Update()
	{
		if(Input.GetKeyDown(KeyCode.Escape))
		{
			jump.StateChange -= onStateChange;
			jump.Close();

			joystickX.VoltageRatioChange -= joystickChange;
			joystickX.Close();
			
			joystickY.VoltageRatioChange -= joystickChange;
			joystickY.Close();
			
			Application.Quit();
		}
	}

On the assumption that jump, joystickX, and joystickY are my Phidget devices (using a thumbstick phidget to control the ball instead of arrow keys on keyboard).

[thylaxene]

There is certainly an issue with the Editor not releasing the Phidget library or something after use. When I connect and test in the Editor the RFID reader via the DLL I'll get a reading off tags fine during play mode. But once I exit play mode, even with proper cleanup I will hang Unity Editor on any script re-compile. Which obviously happens a lot during development.

The standalone build on macOS works fine and doesn't seem to hang on quit or anything. So my work around is for development I ping a Python script via the Editor and the build uses the DLL. For now this is letting me reach deadline.

But be nice to figure what is going on with the Editor.

Cheers.

[daves0]

thylaxene, my Unity Editor would crash out completely (not just hang) when the phidget's Open() call next occurred after a successful run from the Editor. Given things like DontDestroyOnLoad and similar trickery used to keep things "alive" within Unity, it is possible that your application is executing the Phidget Open() call on your device immediately after compilation, and that call is then locking you up? If you're lucky you might see something in the Editor.log file .. I did occasionally.

Like you, I don't run with Phidgets in my development environment due to the cleanup issues. Hopefully some progress can be made here as we share info and experiences. Thanks for your input!

[burley]

There is certainly an issue with the Editor not releasing the Phidget library or something after use. When I connect and test in the Editor the RFID reader via the DLL I'll get a reading off tags fine during play mode. But once I exit play mode, even with proper cleanup I will hang Unity Editor on any script re-compile. Which obviously happens a lot during development.

The standalone build on macOS works fine and doesn't seem to hang on quit or anything. So my work around is for development I ping a Python script via the Editor and the build uses the DLL. For now this is letting me reach deadline.

But be nice to figure what is going on with the Editor.

Cheers.

In the time I spent working on it I definitely experienced 1 lock up but I was not able to reproduce it consistently.

[daves0]

For consistent lockups, try something with the PhidgetManager like what I described a few messages up in this thread. That was a repeatable issue that is pretty easy to set up. Let me know if I can be of assistance, if a similar setup still works correctly for you.

[burley]

I can reproduce the issue consistently now but only if I am not closing the manager object properly before terminating the program. If I do close things out properly then the issue does not manifest.

So long as I call objectName.Close(); before Application.Quit(); then I don't get the issue.

[daves0]

We don't call Application.Quit() when running in the Editor. Per Unity's suggestion (sorry, I can't remember where from exactly), the following code is in my game:

Code: Select all

#if UNITY_EDITOR
	UnityEditor.EditorApplication.isPlaying = false;
#else
	//Application.Quit();
	System.Diagnostics.Process.GetCurrentProcess().Kill();
#endif

Note: I'm using the Kill() because the Quit() doesn't work in my stand-alone game.

That "isPlaying" field stops the game from playing but keeps things alive in the Unity Editor. From what you are saying, it sounds like the Unity "isPlaying" field doesn't properly halt or clean up our code, which is unfortunately not surprising. thylaxene, does doing some Phidget-related cleanup manually in your code at exit-within-Editor time resolve your crash issues?

If this takes care of the PhidgetManager crashes (and thanks very much for that!), it still leaves my crash on exit with accelerometer events in flight, as that happened even from within a stand-alone executable built from Unity. Brian, were you able to get crashes from a Unity game when you quit it while shaking an accelerometer? (with proper clean-up code of course).

[thylaxene]

Here is my clean up code:

Code: Select all

private void OnDestroy()
{
	CleanUp();
}

private void CleanUp()
{
        if (_reader == null) return;
        _reader.Tag -= ReaderOnTag;
        _reader.Close();
        _reader = null;
        Phidget.FinalizeLibrary(0);
}

I use OnDestroy because it is called both when Play mode ends and on Application.Quit is called or whenever the scene changes or "game" ends.

So as far as I can see we are cleaning up properly.

But the problem is there in the Editor by just opening a connection to the DLL. Like this:

Code: Select all

private void OnEnable()
{
        _reader = new RFID {DeviceSerialNumber = id, Channel = ch, HubPort = hp, IsLocal = true};
        if (_reader == null) return;
        _reader.Tag += ReaderOnTag;
        _reader.Open();
}

Run this code once. Then next code compile after Play stops freezes Unity Editor or hard crashes the Editor on next Play.

100% of the time.

Unity 2018.3.5 macOS.

Edited crash report.

lock 0x14baa4740 failed with 22 (Invalid argument)
unlock 0x14baa4740 failed with 22
lock 0x14baa4740 failed with 22 (Invalid argument)
unlock 0x14baa4740 failed with 22
lock 0x14baa4740 failed with 22 (Invalid argument)
unlock 0x14baa4740 failed with 22
lock 0x14baa4740 failed with 22 (Invalid argument)
unlock 0x14baa4740 failed with 22
lock 0x14baa43b8 failed with 22 (Invalid argument)
lock 0x14baa38c0 failed with 22 (Invalid argument)
unlock 0x14baa38c0 failed with 22
unlock 0x14baa43b8 failed with 22
lock 0x14baa38c0 failed with 22 (Invalid argument)
unlock 0x14baa38c0 failed with 22
lock 0x14baa38c0 failed with 22 (Invalid argument)
unlock 0x14baa38c0 failed with 22
lock 0x14baa38c0 failed with 22 (Invalid argument)
unlock 0x14baa38c0 failed with 22
lock 0x14baa38c0 failed with 22 (Invalid argument)
unlock 0x14baa38c0 failed with 22
Receiving unhandled NULL exception
Obtained 7 stack frames.
Thread 0x700013e4f000 may have been prematurely finalized
#0 0x0000014ba26ad5 in _mos_tlock_lock
Thread 0x700013e4f000 may have been prematurely finalized
#1 0x0000014b9e0f86 in RawDeviceRemoved
Thread 0x700013e4f000 may have been prematurely finalized
#2 0x0000014b9e158f in PhidgetUSBSetupNotifications
Thread 0x700013e4f000 may have been prematurely finalized
#3 0x0000014ba1edf8 in CentralThreadFunction
Thread 0x700013e4f000 may have been prematurely finalized
#4 0x007fff61753339 in _pthread_body
Thread 0x700013e4f000 may have been prematurely finalized
#5 0x007fff617562a7 in _pthread_start
Thread 0x700013e4f000 may have been prematurely finalized
#6 0x007fff61752445 in thread_start

Assertion failed on expression: 'Thread::EqualsCurrentThreadID(Thread::mainThreadId)'

Assertion failed on expression: 'CurrentThreadIsMainThread()'

Cheers.

[Patrick]

I'm looking into this more.

Once Phidget.FinalizeLibrary() is called, you cannot make any more calls into the library, so this is not a good solution for working in the editor, as the library does not get loaded/unloaded on each execution.

I can recreate the manager related lockup, so I'm looking into that now. Probably can recreate the Spatial crash as well, we'll see.

-Patrick

[thylaxene]

Ah that makes sense. I added that call in desperation. I'll remove it and sees what happens.

Cheers.