Well I did do some testing. The leak was very small (1k over 10 min run) but
only when one does
$shift->FETCH( 'ParamValues' ),
in the child callback.
Tim what would the impact of the above?? I know before 1.63 this
$shift->{ParamValues'},
gave you undef which is why the WTF comment was there.
Why if in the CB we had the outter handle would the FETCH give you the
attributes of the Inner handle??
Just a silly question?
Cheers
> Date: Fri, 31 Jan 2014 17:00:20 +0000
> From: martin.ev...@easysoft.com
> To: tim.bu...@pobox.com; byter...@hotmail.com
> CC: hhferre...@gmail.com; boh...@ntlworld.com; dbi-users@perl.org
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
>
> On 31/01/14 16:21, Tim Bunce wrote:
> > On Fri, Jan 31, 2014 at 09:11:28AM -0500, John Scoles wrote:
> >> A final note on this.
> >>
> >> Seems there was a very very long unknown bug in DBI which was only fix a
> >> few days ago wiht DB 1.6.31
> >
> > If you mean Callbacks getting an inner handle, that wasn't a bug as such.
> > More like a design choice that proved non-optimal.
> >
> >> [1]http://blogs.perl.org/mt/mt.fcgi?__mode=view&_type=entry&id=5570&blog_id=2165
> >
> > That's
> > http://blogs.perl.org/users/byterock/2014/01/callbacks-ate-my-brain.html
> > I presume.
> >
> >> The end result of this bug was that when callbacks are used on the
> >> statement handle some attributes will not be there so you
> >> programmer who did this
> >>
> >> $sth->FETCH( 'ParamValues' ), # WTF? - returns a reference to an array of
> >> hashes
> >>
> >> was most likely complaing that the
> >>
> >> $sth->{ParamValues},
> >>
> >> should return a ref but was just returning undef.
> >>
> >> So he 'Kludged' the code to get the value directly with the FETCH which
> >> works
> >
> > I'm not sure what you're saying here John. Using $sth->FETCH('ParamValues')
> > is perfectly reasonable. It was required before 1.631 and optional with
> > 1.631+ now that $h->{ParamValues} works.
> >
> >> sort of, but it does bleed memory every so slighly.
> >
> > Are you sure? This is the first I've heard of such a leak.
> >
> > Tim.
>
> I've found no evidence of a memory leak with a simple test calling
> ParamValues a lot with some parameters. However, I'm not using
> ORA_VARCHAR2_TABLE. The code is:
>
> else if (kl==11 && strEQ(key, "ParamValues")) {
> HV *pvhv = newHV();
> if (imp_sth->all_params_hv) {
> SV *sv;
> char *key;
> I32 keylen;
> hv_iterinit(imp_sth->all_params_hv);
> while ( (sv = hv_iternextsv(imp_sth->all_params_hv, &key, &keylen)) ) {
> phs_t *phs = (phs_t*)(void*)SvPVX(sv); /* placeholder struct */
> (void)hv_store(pvhv, key, keylen, newSVsv(phs->sv), 0);
> }
> }
> retsv = newRV_noinc((SV*)pvhv);
> cacheit = FALSE;
>
> }
>
> which looks sane to me right now. ORA_VARCHAR2_TABLE seems to do strange
> things with parameters I don't quite get right now.
>
> As I said previously to Hélder and John (some of the discussion was off
> dbi-users list presumably because it contained log data), although I accept
> taking the call to ParamValues out has on this occasion made the problem go
> away I don't understand why. I think there is more to this than it so far
> looks but without a way of reproducing it myself I won't be spending any more
> time on it. If it is reproducible in a standalone script I will happily look
> again.
>
> Martin
