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
