native dll locked when unloading AppDomain (windows)

[viceice]

I've a process architecture which uses AppDomains to seperate functionalities.
So one AppDomain can use ClearScript.
When the AppDomain get's unloaded the ClearScriptV8.win-x64.dll file seems to remain locked by windows.

Any buildin way to fix that?

My idea is to copy that file to a temp folder and use AuxiliarySearchPath to let clearscript load the file.

[ClearScriptLib]

Hi @viceice,

ClearScript uses DllImportAttribute to invoke native methods. When it does so, the .NET runtime acquires a reference to the native library, loading it if necessary. Our understanding is that it never releases that reference.

In some legacy environments – as well as deployments where the native library is in a custom location – ClearScript can manually load the native library before any native calls take place; that's where AuxiliarySearchPath can be useful. ClearScript then releases its reference when all V8ScriptEngine and V8Runtime instances have been disposed. Unfortunately, the .NET runtime retains its reference, so the library remains locked until process termination.

A post on StackOverflow suggests that one could work around that by double-releasing a manually loaded library reference, but ClearScript doesn't do that. We feel that it's a dangerous hack, and no users have asked for it until now.

Perhaps we could implement forced library release as an opt-in feature. Can you tell us more about your use case?

Thanks!

[ClearScriptLib]

@AudriusButkevicius The method V8SplitProxyManaged.CreateMethodTable constructs a table of native-to-managed call thunks. This method is used to initialize a static property, so it's invoked once within each context that uses V8. Currently there's no mechanism for releasing the resources it allocates. In typical single-context applications, that's not a concern at all.

[AudriusButkevicius]

You are totally on the money.

Added a hack that exposes that object as a public, added a static list to collect the GC handles, and a method that you can call to free the handles, and it unloads properly.

I can even load and unload it multiple times, as new ALCs reinitialise the statics no problem.

What would be a sensible way to expose this?

Something that gets called as part of OnEntityHolderDestroyed, after freeing the native library?

[AudriusButkevicius]

Seems that there is also something about raising exceptions to the host, once it's raised, seems that stuff cannot be freed.

Any pointers on this one?

[ClearScriptLib]

Hi @AudriusButkevicius,

Something that gets called as part of OnEntityHolderDestroyed, after freeing the native library?

Hmm, that's a very interesting idea – automatic and safe, with no clunky new APIs required. It should probably be done before unloading the native library, and it might be wise to do it asynchronously, as OnEntityHolderDestroyed is called from a finalizer. We'll take a closer look.

Seems that there is also something about raising exceptions to the host, once it's raised, seems that stuff cannot be freed.

What happens in that case? Does the final OnEntityHolderDestroyed not get called? That is, does splitImplCount not transition back to zero? In any case, automatic cleanup as you've described is still an idea worth investigating.

Thank you!

[AudriusButkevicius]

The refcount does go to zero and free does get called, but there must be something related to exceptions that leaks. I checked the AddHostObjRef part where we pass down gc handles into v8, but all those seem to be freed before freeing the library.

Is there some way to get info from the GC whats preventing the cleanup?