[4.0.75.1101] Delphi host unloading .net plugins does not clean-up their memory

I’m using a Delphi host application to load hydra plugins written in delphi/c#. Delphi plugins get the call to PluginDestroy method. In c# plugin I never get a call to the Dispose(bool disposing) method. Which means that hydra is not handling interface references well. I even use garbage collector inside the plugin to clean-up memory, but that dispose method still is not called.

How can this problem be solved? My host application is very big and rewriting it in .net is not an option.

Checked with a completely empty plugin. Dispose is never called and handles are leaking in task manager.

Also noticed that all plugins destructor/finalization code is called only when I call the UnloadModule(…) method. This is absolutely unacceptable.

Hello

Isn’t this as designed? Plugin stays loaded in memory as long as is Module is loaded. You need to move resource management logic to plugin’s startup and shutdown methods.

Regards

The problem is that we are using both types of plugins: delphi and .net. Delphi plugins are destroyed the moment I call THYModuleManager.FreeInstance(…).

With .net plugins that does not happen. All allocated resources (including custom controls, labels, panels etc.) don’t get released and after about 2 hours of running, the application memory usage increases from ~80MB to ~650MB and at that point (depending on available memory in a machine) it crashes.

Also I already have custom variables clean-up based on the HostChanged event, where I check if Host property is null and release my custom non-visual variables. The visual controls should be disposed/freed by the dispose/finalization code of the plugin.

This application I’m working on is part of a CCTV surveillance system and needs to be operational 24/7. Each new DLL module is a driver for separate vendor. Some vendors have SDK’s based on COM, while others are made in .NET.

The problem here is that the way plugins work now is inconsistent: delphi plugins get freed the moment I call THYModuleManager.FreeInstance(…), while .NET plugins wait until I call THYModuleManager.UnloadModule(…). Our application initially was developed in Delphi, but later we had to add .NET plugins support. We did not expect that they would be designed differently. Also we can’t unload the entire module to free a single plugin, because at the same time there might be lots of other plugins open (from the same module).

Thanks, logged as bugs://72373

I added this code to my delphi host application and it works for .net plugins, but the problem is that HostChanged event fires after the plugin gets disposed:

procedure UnloadPlugin(var anInstance : IHYVisualPlugin);
var dsp: IDisposable;
begin
  anInstance.QueryInterface(IDisposable, dsp);
  if (dsp <> nil) then
  begin
    dsp.Dispose;
    dsp := nil;
  end;
  moduleManager.ReleaseInstance(anInstance);
end;

procedure UnloadPlugin(var anInstance : IHYNonVisualPlugin);
var dsp: IDisposable;
begin
  anInstance.QueryInterface(IDisposable, dsp);
  if (dsp <> nil) then
  begin
    dsp.Dispose;
    dsp := nil;
  end;
  moduleManager.ReleaseInstance(anInstance);
end;

With this code the Dispose() method gets called correctly. But after running an overnight test I still see that none of the plugins get released (most likely not all references have been nulled). I’ve used “.NET Memory Profiler” and found out that none of the plugins have been cleaned, since they all are referenced by some code. Since only the host application makes references to the plugin, I suspect this is an internal Hydra problem.

can you upload here (or send to support@) a simple testcase that reproduces this problem, pls?
also a memory snapshot file from your memory profiler will be useful (pls tell which exactly profiler did you use)?

I’m afraid I don’t have a simple example for this. I did more tests and for me it was partially solved when I moved all controls from VisualPlugin to a UserControl wrapper and then used that wrapper inside VisualPlugin.

For memory debugging I have used .NET Memory Profiler (http://memprofiler.com/download.aspx).

Any update on this issue? Even I am observing handle leaks.

it isn’t fixed yet

any update on the issue?