This is what I got from Unity support forums, should be helpful:
Generally the issue is a native thread which is started from managed code and never disposed.
The similar problem was with Phidgets .net library.
They haven't been calling CloseHande on thread when it has been terminated.
So thread was leaking as far as I understood.
But this didn't fix the problem completely:
Yes, this is all on Windows. The Unity editor now works fine and does not hang, however a windows build (32 or 64 bit) will still hang on exit.
It does seem strange that it now works in the editor (3.5.2f2), but not as a windows build. I made numerous tests to ensure I wasn't using
the old .NET.dll and emailed Phidgets to get them to confirm the same thing happened for them. Obviously they fixed the editor bug and
didn't think to test a build at the time.
When you call a managed function from native thread function, the first time mono stores that thread id in its internal list,
but mono doesn't know where that thread is created, when mono shutdowns it goes through that list and waits for all threads to finish,
it also waits for that specific thread to finish
The thread is actually being correctly destroyed by the native plugin, but mono never notices that...
and doesn't remove the thread id from its internal list.
....it could probably check if the thread with specific id exist at all... don't know if it's a bug, or just by design.
In any case, I suggested a workaround for Phidget developer, to destroy that thread from managed land instead of native land,
that way mono will catch it, and remove that thread from the list, and won't stall when shutting down.
And the next guy got exactly the problem I'm having because I pass managed delegates to BASS_ASIO_ChannelEnable:
I've been following this discussion with interest because I've come across a similar issue. I have a callback function on the managed side
which just calls Debug.Log (a simple debug message callback). My native plugin calls the callback from two different threads within the plugin.
(I understand Debug.Log is one of the few thread-safe Unity functions.)
Everything works fine until I try to shut down the editor, at which time the editor locks up. I know the plugin is gracefully shutting down all threads,
however it seems this mono quirk is once again to blame.
You suggest destroying the thread from the managed side. What technique should I use for this?
I've tried saving a reference to the thread using Thread.CurrentThread. However calling Abort() on this has no effect,
presumably because the managed side knows it's an OS thread.
I've tried aborting the thread using kernel32's TerminateThread() function. This successfully kills the thread,
but of course I've bypassed mono here and the lock up problem remains.
And the last solution proposal from the thread:
there's also another solution, you could pass special SECURITY_ATTRIBUTES when calling CreateThread,
because when mono scans threads it wants to kill with OpenThread (THREAD_ALL_ACCESS, TRUE, threadID),
that means if you would create a thread with DELETE restriction, mono woudn't touch that thread while shutdowning.
Hope it will help to nail down the bug.
Show Posts
Reply
Quote