Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Unity crash when stopping simulation (C++ DLL plugin)
#1
Hi, I have been looking into Live++ as a possible solution to improved edit and continue support in a C++ DLL that will be used by Unity.

So far, Live++ has worked very well, as I'm able to run the simulation, which loads the C++ DLL with Live++ support, make changes and have those changes be applied to the Unity simulation.

However I have an issue where Unity will crash when stopping the simulation after a Live++ change. This crash appears to be a null pointer exception in the C runtime, sometimes in memset or an allocator function.

What I discovered, somewhat by accident, is that if I hook into the post-compile callback and reload the DLL in Unity, the crash goes away (and the edits appear to remain).

I'm curious if this is a known issue with Unity (it also happens with Unreal), and whether the potential workaround is a known solution or a red herring, and if you're aware of the "correct" fix, or perhaps you have a deeper understanding of what could be causing this issue?

Let me know if you need anything from me. Much of the code is behind NDA but I can try and provide as much information as possible.

Thanks in advance,
-wshack
Reply
#2
Hi,

(04-26-2021, 08:36 AM)wshack Wrote: if I hook into the post-compile callback and reload the DLL in Unity, the crash goes away (and the edits appear to remain)

Can you explain what reloading the DLL in Unity means in this context? If that does a Win32 LoadLibrary call under the hood, it means that the process' reference count for that DLL will be increased. This in turn suggests that the crash might be happening because the C++ DLL (or any of its Live++ patches) is released/unloaded too early, but existing code still tries to call into it.

How and where do you register the DLL with Live++, and what do you do before the DLL is unloaded (presumably by Unity)?

Is the situation in Unreal exactly the same? We are not aware of any issues with Unreal plugin DLLs.

Thanks,
Stefan
Reply
#3
(04-26-2021, 09:13 AM)Stefan Reinalter Wrote: Hi,

(04-26-2021, 08:36 AM)wshack Wrote: if I hook into the post-compile callback and reload the DLL in Unity, the crash goes away (and the edits appear to remain)

Can you explain what reloading the DLL in Unity means in this context? If that does a Win32 LoadLibrary call under the hood, it means that the process' reference count for that DLL will be increased. This in turn suggests that the crash might be happening because the C++ DLL (or any of its Live++ patches) is released/unloaded too early, but existing code still tries to call into it.

How and where do you register the DLL with Live++, and what do you do before the DLL is unloaded (presumably by Unity)?

Is the situation in Unreal exactly the same? We are not aware of any issues with Unreal plugin DLLs.

Thanks,
Stefan

Hi, thanks for the reply.

Yes, by reloading I'm referring to a Win32 LoadLibrary call (called via Kernel32.dll in Unity in this case).

The DLL has a "startup" function that initialises all internal systems, and configuring Live++ is the first thing it does. We're using a "hot reloading" method with Unity (again using Kernel32.dll's functions), but the crash also happens when using the [dllimport] attribute.

The C++ init code:
Code:
HMODULE livePP = lpp::lppLoadAndRegister(L"path/to/LivePP", "lib");
lpp::lppEnableAllCallingModulesSync(livePP);
lpp::lppInstallExceptionHandler( livePP );

// lib init code follows...

Currently there's no sync points.

There's a shutdown function called before the DLL is unloaded (done by calling Win32's FreeLibrary). It's within the FreeLibrary call that the asserts fire.

Here's the steps:
Awake() -> LoadLibrary() -> Startup() (initialises Live++ in the DLL) ...
OnDisable() -> Shutdown()
OnDestroy() -> FreeLibrary()

There's a very good chance this is happening due to user error, however I just discovered my local trial has expired so I'm unable to perform some tests, is there a way to extend the trial at all?

I'm evaluating the use of Live++ for a company, but we want to resolve potential workflow issues before taking it on.

Thanks,
-wshack
Reply
#4
Thanks for the explanation, I'd like to take a thorough look at this.

Can you please write to us at support@molecular-matters.com?



I can also extend your trial.
Reply
#5
For future reference, this issue was solved by adding the necessary lpp::lppDisable*() and lpp::lppShutdown() API calls before unloading the Live++ and C++ DLLs.

The lpp::lppShutdown() calls were missing in the documentation, which has been fixed accordingly.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)