Unity 3 game with Pinvoke Hangs on exit

Unity Engine
1

Hello,

we’re developing a .net library which relies on native codes. It worked fine in Unity 2.6 but now that we test it on unity 3, the very same setup (unity project + c# wrapper + native lib) has issues.
Basically, everything runs fine. but when we try to exit a built game (.exe), the game hangs forever and I have to kill it.
In debug in the UnityEditor everything goes fine we can start stop start stop the game multiple time, but when we exit the UnityEditor it hangs aswell.

So basically, it all worked in 2.6 but doesn’t work in 3.0 with the very same setup. As Tak NCarter proposed on irc, I tried connecting the vs debugger to the running game but everything seems fine. When the game is hanging all the threads are in mono/unity related code (our library’s threads have already been cleaned up as far as I can see).
Also our library has already been used in mono on ubuntu w/o problems.

Any Idea ?

2

This sounds similar to an issue I’m having with a C++ dll. Definitely a new issue with Unity 3.0. Same hang when calling Application.Quit() or using the window X to close.

3

after a long investigation we discovered that the bug occurs when we register callbacks (native calling managed). we managed to reproduce it in a small project which I emailed to the unity support.

4

Glad to see you narrowed it down. Please keep us up to date on this. Thanks!

5

How are you able to get mixed-mode assemblies (assemblies containing both managed and unmanaged code, which Managed C++ can produce) in Unity? When I try to do this, I just get the error:

MissingMethodException: Method contains unsupported native code
..LanguageSupport.Initialize (.LanguageSupport* )

Thanks in advance.

6

I fear this is nothing new.
async stuff calling in from a thread or outside must be unhooked before ending or will backfire.
Best known case are async sockets

7

dreamora: that’s not the issue. we tested that.

We’ve received an answer from UT, they say they don’t support managed code being called from unmanaged threads at all and that it was only luck that it worked on 2.6. So, basically, we’re screwed as changing the threading model of our huge native library is not really an option.
we’re currently pondering what our options are and will probably get back in touch with UT soon.