possible leak in 1.52

Hi.

I'm running 1.52 and I may have found a leak ( i found a discussion
reported on the 1.51 branch, and a patch to 1.52, so i think this
might be different )

I was profiling some mod_perl code for unexplained growth with
Devel::Leak, and came across a growth of 1 reference count with every
call to $dbh->prepare ( also to $dbh->do , but it seems to just
wrap prepare ).

the growth seems to happen regardless of parameters supplied to do /
prepare

my $handle;
my $count= Devel::Leak::NoteSV($handle);
=snip
my $query= $dbh->prepare( 'SELECT id FROM my_table' );
=snip
print STDERR "\n Count before: " . $count;
print STDERR "\n ------------------------------------------";
my $count_after= Devel::Leak::CheckSV($handle);
print STDERR "\n Count after: " . $count_after;
print STDERR "\n Leaked: " . ( $count_after - $count );

If i comment out the do/prepares, I have no leaks in reference counts.

Now , i'm using DBD::Pg with this, and it very well could be an
issue with that driver and not the DBI. unfortunately, I can't
install any other DB on my machines to test.

I haven't been able to trace things within DBI , as I'm not that
familiar with it.

Off a fresh apache start, a call to the DBD prepare will cause a
growth of ~10 references, then ~5, and then 1 per request. Between
this and some other things online, I kind of think that it might have
to do with DBI's caching of the statement. I couldn't find that in
the code though.

Re: possible leak in 1.52

it definitely seems to be a leak, and i've been able to reproduce it
outside of mod_perl

it seems that there are a few potential sources / behaviors

a_ the statement handle created by a prepare never seems to expire
in the lifetime of a db connection
i could trace this as far back as
DBI::_new_handle

b_ if i connect, run 100 'update x where y=z' , then disconnect, no
SV are released

c_ if i then undef my db handle, a lot of SV are freed - but i seem
to have a 138 SV which are not released

d_ if i reconnect , i seem to use only 15 more SV than the original
connect- whereas the original connect used 231 SV over my test
platforms 'weight'

e_ if i undef the reconnect, I seem to have leaked 1 SV since the
first disconnect

unfortunately, thats as far as my DBI knowledge can take me

Re: possible leak in 1.52

On Aug 23, 2006, at 8:55 AM, Ephraim Dan wrote:

> I hope Tim will chime in and correct me, but since I was the last
> reporter of leaks in the DBI, let me try my best:

great.... i'll try all that stuff than let you know

Re: possible leak in 1.52

On Aug 23, 2006, at 8:55 AM, Ephraim Dan wrote:

> I tried to reproduce your leak without success. Perhaps you are
> not letting your test run for enough iterations. DBI does cache
> some handles that it only releases every 120 calls. So you could
> see what looks like a 1 SV leak, but you'll see that after 120
> iterations they are all freed.

OK. I tried 200, and that seemed to clear up a large number of them,
and anything i was worried about. SVs went down by 120 every 120 calls

this doesn't apply to my needs, but are DB connects cached as well
with a separate 120 counter?

using pg, i saw this

count CONNECT3 : 14427
count undef3 : 14320
count CONNECT4 : 14428
count undef4 : 14321

the code for that was just

$dbh = DBI->connect( $_db_config{'dbi'}, $_db_config{'dbUser'},
$_db_config{'dbPass'} , $_db_config{'dbArgs'} ) or die "Could not
connect";
$count= Devel::Leak::NoteSV($handle);
print STDERR "\n count CONNECT3 : $count ";
undef $dbh;
$count= Devel::Leak::NoteSV($handle);
print STDERR "\n count undef3 : $count ";
$dbh = DBI->connect( $_db_config{'dbi'}, $_db_config{'dbUser'},
$_db_config{'dbPass'} , $_db_config{'dbArgs'} ) or die "Could not
connect";
$count= Devel::Leak::NoteSV($handle);
print STDERR "\n count CONNECT4 : $count ";
undef $dbh;
$count= Devel::Leak::NoteSV($handle);
print STDERR "\n count undef4 : $count ";