Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Run time linked dll and memory leak

by nikosv (Hermit)
on Jun 24, 2010 at 09:10 UTC ( #846258=perlquestion: print w/ replies, xml ) Need Help??
nikosv has asked for the wisdom of the Perl Monks concerning the following question:

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?

Comment on Run time linked dll and memory leak
Re: Run time linked dll and memory leak
by kejohm (Hermit) on Jun 24, 2010 at 09:48 UTC

    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.

Re: Run time linked dll and memory leak
by BrowserUk (Pope) on Jun 24, 2010 at 10:04 UTC
    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.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      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!

        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.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://846258]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (11)
As of 2014-10-23 08:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (125 votes), past polls