Re: DBI::_new_handle leak?

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 leek 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.
.

Relevant Pages