Run time linked dll and memory leak

[nikosv]

I have a Perl/Tk application which is loading and calling functions from a C++ dll using the Win32::API module. These functions are being called repeatedly from within a loop.

Under heavy load (after many iterations over these functions),the whole app hangs(does not crash) which probably shows that there is a memory leak.

In the beginning I started looking for GDI and handle leaks but the numbers throughout the application's run are constant whith very small deviation.

The only way I managed under heavy load to make the app run into completion is when I unload and reload the dll from memory (Getmodulehandle,Freelibrary) after a number of iterations. This probably shows that the dll is not releasing memory and instead it increasingly consumes more until the app hangs.

Is that (unloading and reloading the dll) standard procedure when calling repeatedly run time linked dll's, or am I doing something out of the norm and should look for leaks elsewhere?

[BrowserUk]

Is that (unloading and reloading the dll) standard procedure when calling repeatedly run time linked dll's,

No. This is definitely not SOP.

If doing so is actually free up sufficient memory to make a substantial difference to your application, you ought to be able to see that quite clearly reflected in the memory usage graph/numbers in the Task Manager or Process Explorer. But then, if that were the case, I would have expected you to be a lot more positive than "probably shows that there is a memory leak." & "This probably shows that the dll is not releasing memory"

It could be that calls into the dll are allocating memory or objects that users of the dll are meant to free themselves, but I'd expect that to be relatively obvious from the API documentation.

Another common possibility is that the dll was built using a different runtime library to that of the Perl build you are using, and that is the source of the problem. But again, it should be fairly easy to identify this using Process Explorer.

Were I attempting to debug this, the first thing I do is compile a 10 line C app that calls the same APIs in the DLL in a loop and see what happens. If the hang still occurs, then it will become clear that the problem is in the dll.

If not, then I'd try shifting from using Win32::API to Inline::C to try and isolate that possibility.

But both those require you have access to both the DLL and a compiler.

There's not much more than can be suggested without lots more information.

[nikosv]

Some great paths to follow,thanks.

Using process explorer the handle numbers and memory usage look stable at first sight but I will also take a look with Windbg.

Are there any good memory leak detection/profiling tools for the win32 platform i.e similar to Valgrind ? and while on the subject..., any good Perl targeted tools/modules? I've heared of Devel::Gladiator but I haven't used it yet;maybe it's time to start now!

[BrowserUk]

Are there any good memory leak detection/profiling tools for the win32 platform i.e similar to Valgrind ?

Take a look at MS Application Verifier.

I've never used (nor even heard of until now), Devel::Gladiator. It certainly looks interesting, and both the authorship and maintainer are indicators of goodness.

[kejohm]

What sort of functions are you using and what are you doing with them? If you are using GDI functions, you may have to release objects, such as DCs, when you are done with them.