DBI::_new_handle leak?

I'm searching for memory leaks in an application.  Devel::LeakTrace::Fast
has pointed me at DBI::_new_handle(). I was wondering if anyone can
point out that I'm using bad versions, or if I'm mislead by the tool
(Devel::LeakTrace::Fast).

I searched the mailing list and found:

http://www.mail-archive.com/dbi-use...g/msg28092.html

Which seems to match what I'm seeing, except for the fact that
I'm not seeing the statement handles released after 120 calls.

So let me explain.  I'm seeing a memory leaks in a daemon that
interacts with a MySQL database.  I'm using Devel::LeakTrace::Fast
to help track down the leaks.  During a 15 minutes sample it says that
there where 148 "leaked" SVs which were created by DBI::_new_handle()

First, has anyone else tried using Devel::LeakTrace::Fast? Are its
results reliable?  Realizing that a report about leaks happening is an
application that I don't provide code for is not a valid report.  What
is the minimum script I should use to try and provide a mechanism
to reproduce?

Second, is the 120 handle cache size modifiable by the user?

Here are the versions of software involved:
DBI 1.604
DBD::mysql 4.006
perl 5.8.8
Devel::LeakTrace::Fast 0.11

Thank you in advance.
-- 
James R. Leu
jleu@mindspring.com

On Fri, May 09, 2008 at 11:31:46AM -0500, James R. Leu wrote:
> I'm searching for memory leaks in an application.  Devel::LeakTrace::Fast
> has pointed me at DBI::_new_handle(). I was wondering if anyone can
> point out that I'm using bad versions, or if I'm mislead by the tool
> (Devel::LeakTrace::Fast).

> So let me explain.  I'm seeing a memory leaks in a daemon that
> interacts with a MySQL database.  I'm using Devel::LeakTrace::Fast
> to help track down the leaks.  During a 15 minutes sample it says that
> there where 148 "leaked" SVs which were created by DBI::_new_handle()

> Realizing that a report about leaks happening is an application that I
> don't provide code for is not a valid report.  What is the minimum
> script I should use to try and provide a mechanism to reproduce?

You've two choices: cut-down or build-up. Either cut-down the existing
code until you can't cut away anything else without the l stopping.
Or build-up a small script from scratch that demonstrates the leak.

The first way can be time consuming but is always effective because you
already have a reproducible leak. The second is worth a quick-try, but
if you can't reproduce the leak quickly then it gets very risky.

I'd suggest you give the build-up approach a try for an hour or three
then, if you've no luck, move the the cut-down approach.

> Second, is the 120 handle cache size modifiable by the user?

No. Though you could prune the contents of $h->{ChildHandles} yourself
before the leak check is performed.  But note that we're talking about
*weak* references, so they should not be the cause of a leak.

I'll happily help find and fix a leak in the DBI *if* you can provide me
with a small self-contained example that demonstrates a leak in the DBI.
(Either by using only drivers shipped with the DBI, or demonstrating the
leak with more than one third-party driver.)

Tim.