Re: Possible memory leak in DBI

It would appear this problem and possibly other leaks are attracting quite a lot of attention now. Someone else just posted another cpan rating mentioning leaks at:

  http://cpanratings.perl.org/dist/DBD-Pg#8254

I narrowed down one of the problems (below) but it is beyond me now - sorry.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

On 13/01/11 18:53, Martin J. Evans wrote:
> I briefly looked at the DBD::Pg rt ticket https://rt.cpan.org/Ticket/Display.html?id=60863 and I'm not sure this is a bug in DBD::Pg and think it might be in DBI. Since ShowErrorStatement set causes the leak and unset the leak goes away I isolated it to some code in DBI.xs:
>
> if ( DBIc_has(imp_xxh, DBIcf_ShowErrorStatement)
> && !is_unrelated_to_Statement
> && (DBIc_TYPE(imp_xxh) == DBIt_ST || ima_flags & IMA_SHOW_ERR_STMT)
> && (statement_svp = hv_fetch((HV*)SvRV(h), "Statement", 9, 0))
> && statement_svp && SvOK(*statement_svp)
> ) {
> SV **svp = 0;
> sv_catpv(msg, " [for Statement \"");
> sv_catsv(msg, *statement_svp);
>
> /* fetch from tied outer handle to trigger FETCH magic */
> /* could add DBIcf_ShowErrorParams (default to on?) */
> #ifdef THIS_ONE_STOPS_LEAK
> if (!(ima_flags & IMA_HIDE_ERR_PARAMVALUES)) {
> svp = hv_fetch((HV*)DBIc_MY_H(imp_xxh),"ParamValues",11,FALSE);
> if (svp && SvMAGICAL(*svp))
> mg_get(*svp); /* XXX may recurse, may croak. could use eval */
> }
> #endif
> if (svp && SvRV(*svp) && SvTYPE(SvRV(*svp)) == SVt_PVHV && HvKEYS(SvRV(*svp))>0 ) {
> #ifndef THESE_TWO_WITHOUT_ABOVE_DOES_NOT_STOP_LEAK
> SV *param_values_sv = sv_2mortal(_join_hash_sorted((HV*)SvRV(*svp), "=",1, ", ",2, 1, -1));
> #endif
> sv_catpv(msg, "\" with ParamValues: ");
> #ifndef THESE_TWO_WITHOUT_ABOVE_DOES_NOT_STOP_LEAK
> sv_catsv(msg, param_values_sv);
> #endif
> sv_catpvn(msg, "]", 1);
> }
> else {
> sv_catpv(msg, "\"]");
> }
> }
>
> I was suspicious about _join_hash_sorted but it appears if you just take THESE_TWO_WITHOUT_ABOVE_DOES_NOT_STOP_LEAK out it still leaks.
>
> If you just take THIS_ONE_STOPS_LEAK (which obviously also takes out the other 2) the leak goes away.
>
> I've not duplicated the problem with any other DBDs as yet but I'm running the exact code in the RT.
>
> I've no idea as yet what the actual problem is.
>
> I was running Perl 5.10.1 on Linux (32bit) but no one who has tried this yet (on multiple Perls in Linux) has failed to see the issue.
>
> With THIS_ONE_STOPS_LEAK defined I get:
>
> martin@bragi:/tmp/DBD-Pg-2.17.2$ perl -I blib/lib -I blib/arch leak.pl
> Cycles: 2000 Proc size: 13700K
> Cycles: 4000 Proc size: 13700K
> Cycles: 6000 Proc size: 13700K
> Cycles: 8000 Proc size: 13700K
> Cycles: 10000 Proc size: 13700K
> Cycles: 12000 Proc size: 13700K
> Cycles: 14000 Proc size: 13700K
> Cycles: 16000 Proc size: 13700K
> Cycles: 18000 Proc size: 13700K
>
> and a stock DBI from trunk) I get:
>
> martin@bragi:/tmp/DBD-Pg-2.17.2$ perl -I blib/lib -I blib/arch leak.pl
> Cycles: 2000 Proc size: 16792K
> Cycles: 4000 Proc size: 19892K
> Cycles: 6000 Proc size: 22980K
> Cycles: 8000 Proc size: 26200K
> Cycles: 10000 Proc size: 29296K
> Cycles: 12000 Proc size: 32376K
> Cycles: 14000 Proc size: 35472K
> Cycles: 16000 Proc size: 38692K
> Cycles: 18000 Proc size: 41796K
>
> Martin
>