views:

55

answers:

1

I am using Devel::LeakTrace::Fast to debug a memory leak in a perl script designed as a daemon which runs an infinite loop with sleeps until interrupted. I am having some trouble both reading the output and finding documentation to help me understand the output. The perldoc doesn't contain much information on the output. Most of it makes sense, such as pointing to globals in DBI. Intermingled with the output, however, are several

leaked SV(<LOCATION>) from (eval #) line #

Where the numbers are numbers and <LOCATION> is a location in memory. The script itself is not using eval at any point - I have not investigated each used module to see if evals are present. Mostly what I want to know is how to find these evals (if possible).

I also find the following entries repeated over and over again

leaked SV(<LOCATION>) from  line #

Where line # is always the same #. Not very helpful in tracking down what file that line is in.

+3  A: 

You may not be using eval anywhere directly, but some module you are using likely is. Additionally, there could be a problem in some XS code you are linking into.

Have you tried reducing your script bit by bit, cutting out parts that you think might be suspect (or even parts that you think are not), and seeing how your results change? If you can split your script up into discrete pieces (which is a good idea to do anyway, from an architectural and maintainability standpoint), you might be able to find which area is the culprit, and then drill down from there.

Ether
By discrete pieces are you recommending discrete modules? Removing portions of the script?
justkt
@kt: either or both... basically try to do a binary search within the code to determine where the problem lies. (As an aside, because your username is only two characters long, you won't get @username notifications in your user activity screen.)
Ether
(Hm...maybe tweaking the name will help. Thanks @Ether.)Am in the process of removing chunks of code to isolate where the leak may be. I'll report back. All I get out of the mounds from Devel::LeakTrace::Fast so far is that Log4perl does things that may be memory leaks.
justkt
I isolated the issue by cutting pieces out. A module that I included was SWIG-ed, and there was a conflicting SWIG interface pulled in later on my @INC that conflicted with it. This was causing the first module to never let go of some shared memory. So, I'm marking this as the answer. I'd still like to know what is up with Devel::LeakTrace::Fast showing those empty lines, though, if anyone has a suggestion!
justkt