Hi Guys,
We have run a test with the latest DBI (1.631) and DBD (1.68) versions but
the same error persists. Our perl version is Active Perl v5.12.1.
However, we were able to generate a segmentation fault with a similar test
case passing as input 5000 test items in the arrays.
The core file info contains the following:
*#0 dbih_getcom (hrv=0x20202020) at DBI.xs:1133*
*#1 0xf6de5ae3 in XS_DBD__Oracle__st_execute (my_perl=0x9d3f008,
cv=0xaa21ba8) at ./Oracle.xsi:579*
*#2 0xf6e3347b in XS_DBI_dispatch (my_perl=0x9d3f008, cv=0xa93d160) at
DBI.xs:3746*
*#3 0x080d2e1f in Perl_pp_entersub ()*
*#4 0x080cb3b2 in Perl_runops_standard ()*
*#5 0x08074b02 in S_run_body ()*
*#6 0x0807499a in perl_run ()*
*#7 0x08060ded in main ()*
*(gdb) f 0*
*#0 dbih_getcom (hrv=0x20202020) at DBI.xs:1133*
*1133 if ( SvROK(poolparty)*
*(gdb) l*
*1128 {*
*1129 MAGIC *mg;*
*1130 SV *sv;*
*1131*
*1132 /* short-cut common case */*
*1133 if ( SvROK(poolparty)*
*1134 && (sv = SvRV(poolparty))*
*1135 && SvRMAGICAL(sv)*
*1136 && (mg = SvMAGIC(sv))*
*1137 && mg->mg_type == DBI_MAGIC*
Variable names are suggestive :)
We are a bit lost at the moment.. Any hint that can head us on the right
direction would be very appreciated.
Let me know in case you need further information to better analyze this
problem.
Thanks in advance.
Best Regards,
Hélder Hugo Ferreira
On Fri, Jan 24, 2014 at 3:41 PM, John Scoles <byter...@hotmail.com> wrote:
> Looking at the code changes I was mistaken that this has anyting to do
> with the native_execute aray. My Bad on that.
> That code had been around for a very long time well before 2005.
>
> As the value changes I would think there is some memory leak somplace that
> is corrupting the the 'all_params_hv' deep inside the 'c' struct?
>
> cheers
> ------------------------------
> Date: Fri, 24 Jan 2014 15:34:44 +0000
>
> Subject: Re: Issues with DBI Oracle Input Array Binds (ORA_VARCHAR2_TABLE)
> From: hhferre...@gmail.com
> To: boh...@ntlworld.com
> CC: martin.ev...@easysoft.com; byter...@hotmail.com; dbi-users@perl.org
>
> Theá3443804ávalue is the one we get most of the times but distinct values
> were already seen and were also big number which make no sense... Do you
> know if this function has been changed since DBD version 1.21?á
>
>
> All points out to be a memory leak I guess...
>
> Thanks!
> HÚlder
>
>
> On Fri, Jan 24, 2014 at 3:21 PM, Martin J. Evans <boh...@ntlworld.com>wrote:
>
> On 24/01/14 14:59, hhferreira wrote:
>
> Hi Guys,
>
> We have made the dump of the contents of /$sth->{ParamValues} /into the
> attached file which basically contains all values set for the 6 input binds
> (ora_varchar2_table elements actually).
>
>
> Looks good to me. wc -l on the file shows 9389 and / 6 = ~ 1564
>
> I cannot as yet explain why dbdxst_bind_params thinks there are 3443804
> parameters.
>
> Even in hex 3443804 is 348c5c so it doesn't look like an overflow.
>
> The code reporting the issue is as follows:
>
> static int
> dbdxst_bind_params(SV *sth, imp_sth_t *imp_sth, I32 items, I32 ax)
> {
> á á /* Handle binding supplied values to placeholders. á á á á á*/
> á á /* items = one greater than the number of params á á á á á á*/
> á á /* ax = ax from calling sub, maybe adjusted to match items á*/
> á á dTHX;
> á á int i;
> á á SV *idx;
> á á if (items-1 != DBIc_NUM_PARAMS(imp_sth)
> á á á á && DBIc_NUM_PARAMS(imp_sth) != DBIc_NUM_PARAMS_AT_EXECUTE
> á á ) {
> á á á á char errmsg[99];
> á á á á /* clear any previous ParamValues before error is generated */
> á á á á SV **svp = hv_fetch((HV*)DBIc_MY_H(imp_
> sth),"ParamValues",11,FALSE);
> á á á á if (svp && SvROK(*svp) && SvTYPE(SvRV(*svp)) == SVt_PVHV) {
> á á á á á á HV *hv = (HV*)SvRV(*svp);
> á á á á á á hv_clear(hv);
> á á á á }
> á á á á sprintf(errmsg,"called with %d bind variables when %d are needed",
> á á á á á á á á (int)items-1, DBIc_NUM_PARAMS(imp_sth));
> á á á á DBIh_SET_ERR_CHAR(sth, (imp_xxh_t*)imp_sth, "-1", -1, errmsg,
> Nullch, Nullch);
> á á á á return 0;
> á á }
>
>
> and I don't particularly like that casting but I don't think it explains
> the problem.
>
> Martin
>
> We will proceed with the test environment setup using the latest perl
> and module versions, Martin mentioned this could be done without actually
> installing (overwriting) our existing versions, I suppose you are referring
> to those environment variables such like PERL5LIB which we can tweak to use
> the right versions right? Or there is a better approach? Our working
> environment is rather complex (big company overweight) and that task can
> take a while although seems simple to perform so if there is a simple way
> do let us know :-)
>
> Thanks for your hints!
>
> Best Regards,
> HÚlder Hugo Ferreira
>
>
>
> On Fri, Jan 24, 2014 at 1:28 PM, Martin J. Evans <
> martin.ev...@easysoft.com <mailto:martin.ev...@easysoft.com>> wrote:
>
> á á On 24/01/14 12:26, hhferreira wrote:
>
> á á á á Hi,
>
> á á á á We have already tried using ora_maxarray_numentries and other
> similar attributes unsuccessfully.
>
> á á á á Martin found that immediately before the error the following
> message is written:
> á á á á á á{{ execute callback CODE(0xb832be8) being invoked
>
> á á á á However we have done a dbi_trace with 1000 elements in the arrays
> (which works!) to see whether a similar message is logged and it is, so I
> would not go into that direction though. Will setup a test environment
> using the latest DBD and DBI versions to see whether the leaks in DBD are
> causing this behavior.
>
> á á á á Thanks.
>
> á á á á Best Regards,
> á á á á HÚlder Hugo Ferreira
>
>
> á á The reason I pointed out the execute callback is that it is only
> called just before the failure and we cannot see from the trace what code
> is in it. If we cannot see the code who knows what it is doing?
>
>
> á á 1 á -> FETCH for DBD::Oracle::st (DBI::st=HASH(0xd077218)~INNER
> 'ParamValues') thr#8916008
> á á 1 á <- FETCH= ( HASH(0xd0758e8)7keys ) [1 items] at /home/
>
> á á Might have been interesting if we knew what was in it.
>
> á á Perhaps you could get ParamValues just before execute and if execute
> fails catch it and Dumper them.
>
> á á use Data::Dumper;
> á á .
> á á .
> á á my $pv = $sth->{ParamValues};
> á á eval {
> á á á á á á á$sth->execute;
> á á };
> á á if (my $ev = $@) {
> á á á á á á áprint Dumper($pv);
> á á á á á á ádie $ev;
> á á }
>
> á á However, I still think testing the latest DBI/DBD::Oracle is the best
> thing to do first.
>
> á á Martin
>
>
>
> á á á á On Fri, Jan 24, 2014 at 12:09 PM, John Scoles <
> byter...@hotmail.com <mailto:byter...@hotmail.com> <mailto:
> byter...@hotmail.com <mailto:byter...@hotmail.com>>> wrote:
>
> á á á á á á áAs Martin said that is rather old version of DBD only 3 since
> native exe_array was introduced 1.18, and I rember there being some leaks
> in early version of the native exe_array.
>
> á á á á á á áIf you can upgrade you DBD.
>
> á á á á á á áYyou might try to set the 'ora_maxarray_numentries' áon you
> binds as well as that works on the Oracle side of things to limit memory.
>
> á á á á á á áAs it runs stands alone as you say it might be that the
> things you are binnding are not being released by perl as a referace to
> them may still exist.
>
> á á á á á á áCheers
> á á á á á á áJohn
>
> á á á á á á á > Date: Fri, 24 Jan 2014 10:53:54 +0000
> á á á á á á á > From: boh...@ntlworld.com <mailto:boh...@ntlworld.com>
> <mailto:boh...@ntlworld.com <mailto:boh...@ntlworld.com>>
> á á á á á á á > To: hhferre...@gmail.com <mailto:hhferre...@gmail.com>
> <mailto:hhferre...@gmail.com <mailto:hhferre...@gmail.com>>;
> dbi-users@perl.org <mailto:dbi-users@perl.org>
> <mailto:dbi-users@perl.org<mailto:
> dbi-users@perl.org>>
>
>
> á á á á á á á > Subject: Re: Issues with DBI Oracle Input Array Binds
> (ORA_VARCHAR2_TABLE)
>
> á á á á á á á >
> á á á á á á á > On 24/01/14 10:29, hhferreira wrote:
> á á á á á á á > > Hi Guys,
> á á á á á á á > >
> á á á á á á á > > Hope you can provide us some enlightenment!
> á á á á á á á > >
> á á á á á á á > > We have the following code which basically calls an
> oracle procedure passing as inputs 6 bind arrays (converted in
> ORA_VARCHAR2_TABLE elements) and one string:
> á á á á á á á > >
> á á á á á á á > > /my $sth = $self->prepare( q{/
> á á á á á á á > > / begin pkg_abcdef.pr_setAbcdef(/
> á á á á á á á > > / :in_sourceType,/
> á á á á á á á > > / :in_sourceNames,/
> á á á á á á á > > / :in_peerTypes,/
> á á á á á á á > > / :in_peerNames,/
> á á á á á á á > > / :in_writables,/
> á á á á á á á > > / :in_requireLevels,/
> á á á á á á á > > / :in_testdefs/
> á á á á á á á > > / );/
> á á á á á á á > > / end;/
> á á á á á á á > > /} );/
> á á á á á á á > > /
> á á á á á á á > > /
> á á á á á á á > > /$sth->bind_param( ':in_sourceType', $sourceType, /
> á á á á á á á > > / { ora_type => ORA_VARCHAR2 } );/
> á á á á á á á > > /$sth->bind_param( ':in_sourceNames', $sourceNames, /
> á á á á á á á > > / { ora_type => ORA_VARCHAR2_TABLE } );/
> á á á á á á á > > /$sth->bind_param( ':in_peerTypes', $peerTypes, /
> á á á á á á á > > / { ora_type => ORA_VARCHAR2_TABLE } );/
> á á á á á á á > > /$sth->bind_param( ':in_peerNames', $peerNames, /
> á á á á á á á > > / { ora_type => ORA_VARCHAR2_TABLE } );/
> á á á á á á á > > /$sth->bind_param( ':in_writables', $writables, /
> á á á á á á á > > / { ora_type => ORA_VARCHAR2_TABLE } );/
> á á á á á á á > > /$sth->bind_param( ':in_requireLevels', $requireLevels, /
> á á á á á á á > > / { ora_type => ORA_VARCHAR2_TABLE } );/
> á á á á á á á > > /$sth->bind_param( ':in_testdefs', $testDefs, /
> á á á á á á á > > / { ora_type => ORA_VARCHAR2_TABLE } );/
> á á á á á á á > > /
> á á á á á á á > > /
> á á á á á á á > > /$sth->execute();/
> á á á á á á á > >
> á á á á á á á > >
> á á á á á á á > > The problem is that if we have around 1000 elements per
> array the call works beautifully, but with for instance 1500 it raises an
> exception, namely an invalid number of bind elements!
> á á á á á á á > >
> á á á á á á á > > /19:05:57 ERROR: Caught an exception from DB:
> DBD::Oracle::st execute failed: called with 3443804 bind variables when 7
> are needed [for Statement..."/
> á á á á á á á > > /
> á á á á á á á > > /
> á á á á á á á > >
> á á á á á á á > > Here is the output of dbi_Trace=15:
> á á á á á á á > >
> á á á á á á á > <snipped log>
> á á á á á á á >
> á á á á á á á > As I answered in perlmonks, that log didn't give me enough
> info. Perhaps you could send me personally all the log.
> á á á á á á á >
> á á á á á á á > > PERL version: 5.12.1
> á á á á á á á > > DBI version: 1.611
> á á á á á á á > > DBD::Oracle: 1.21
> á á á á á á á >
> á á á á á á á > That version of DBD::Oracle is very old - 11th April 2008.
> á á á á á á á >
> á á á á á á á > On the other hand your DBI is 19th April 2010.
> á á á á á á á >
> á á á á á á á > I'd rather not debug the issue on versions so old. Is it
> at all possible you can try the latest versions so we can at least see if
> the problem is already fixed? You can do this without actually installing
> (overwriting) your existing versions (ask if you are unsure how to do this).
> á á á á á á á >
> á á á á á á á >
> á á á á á á á > > We have made a standalone script and it works perfectly
> even with 20000 entries per array. In our application we are using perl
> objects all over the code, can this be a memory leak somewhere else in the
> code?!
> á á á á á á á >
> á á á á á á á > Shame, as this would definitely be the best way to go. It
> would be worth putting a bit more effort into this.
> á á á á á á á >
> á á á á á á á > > Any help would be highly appreciated!
> á á á á á á á > >
> á á á á á á á > > Thanks in advance.
> á á á á á á á > >
> á á á á á á á > > Best Regards,
> á á á á á á á > > HÚlder Hugo Ferreira
> á á á á á á á > >
> á á á á á á á >
> á á á á á á á > Martin
>
>
>
>
>
>
>
