Re: DBD::Oracle - execute_array core dumps intermittently
This seems to be a threading error with the linux kernel version. I am running this process on newer kernels (2.6.22.x) and the error never occurs. We also are experiencing a lot the "Futex WAIT" issues with Oracle and the 2.6.20 kernels. Thanks for listening. On Fri, 2008-03-07 at 11:25 -0600, Scott T. Hildreth wrote: > Should have posted to users not dev. This is really a bizarre problem. > I can get it to fail about every fifth iteration otherwise the process > works. I ran it from another server connect to the same database and > it will intermittently fail. I run it from a third sever and I can't > get it to core dump. All 3 servers have the same kernel & Perl > versions. I've tried recompiling Perl, DBI, DBD::Oracle, still no luck. > I created a test case, which uses execute_array and of course I can't > get it to core dump. If anyone has any ideas on what might be going on > here, I would love to hear them! > > Thanks > STH > > On Wed, 2008-03-05 at 15:21 -0600, Scott T. Hildreth wrote: > > I am not sure how to describe this, my co-worker will run his process and > > get a core dump > > (I pasted the back trace below) and then run the process again with no core > > dumps. Sometimes > > it will core dump several times in a row and then the next run it finishes > > fine. I ran the process > > with DBI_TRACE=9 and this is what shows up at the end of the log, > > > > > > 1 -> execute_for_fetch for DBD::Oracle::st (DBI::st=HASH(0xN)~INNER > > CODE(0xN) undef) > > ora_st_execute_array UPDATE count=10 (ARRAY(0xN) undef undef)... > > > > OCIBindByName(112df38,1132188,10a9138,":p1",placeh_len=3,value_p=0,value_sz=-1517274788,dty=1,indp=0,alenp=0,rcodep=0,maxarr_len=0,curelep=0 > > (*=0),mode=2)=ERROR > > OCIErrorGet(10a9138,1,"",7fff058d684c,"ORA-02005: implicit > > (-1) length not valid for this bind or define datatype > > ",1024,2)=SUCCESS > > OCIErrorGet after OCIBindByName (er1:ok): -1, 2005: ORA-02005: implicit > > (-1) length not valid for this bind or define datatype > > > > OCIErrorGet(10a9138,2,"",7fff058d684c,"ORA-02005: implicit > > (-1) length not valid for this bind or define datatype > > ",1024,2)=NO_DATA > > > > At first I thought it was a 32bit library with a 64bit Perl problem, but > > Oracle.so & Perl are both linked > > with the correct 64 bit libs. The Oracle client is 10.2.0.3 and DBI > > versions are, > > > > Perl: 5.008008(x86_64-linux) > > OS : linux (2.6.20.19) > > DBI : 1.602 > > DBD::mysql : 4.005 > > DBD::Sponge : 12.010002 > > DBD::SQLite : 1.13 > > DBD::Proxy : 0.2004 > > DBD::Oracle : 1.20 > > DBD::Multiplex : 2.04 > > DBD::Gofer : 0.010103 > > DBD::File : 0.35 > > DBD::ExampleP : 12.010007 > > DBD::DBM: 0.03 > > > > I am going to try to isolate a small test case, but right now I wanted to > > post what I > > have found so far. > > > > Thanks, > >STH > > > > ## Back Trace > > # > > > > (gdb) bt > > #0 0x2b66ec7d9b95 in raise () from /lib64/libc.so.6 > > #1 0x2b66ec7daf90 in abort () from /lib64/libc.so.6 > > #2 0x2b66ec81035b in __libc_message () from /lib64/libc.so.6 > > #3 0x2b66ec81534e in malloc_printerr () from /lib64/libc.so.6 > > #4 0x2b66ec81695c in free () from /lib64/libc.so.6 > > #5 0x2b66ef0ac102 in ora_st_execute_array () from > > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so > > #6 0x2b66ef0a62bf in XS_DBD__Oracle__st_ora_execute_array () > >from > > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so > > #7 0x0046bc47 in Perl_pp_entersub () > > #8 0x0046a29e in Perl_runops_standard () > > #9 0x0041e82d in Perl_call_sv () > > #10 0x2b66ec9ee038 in XS_DBI_dispatch () from > > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so > > #11 0x0046bc47 in Perl_pp_entersub () > > #12 0x0046a29e in Perl_runops_standard () > > #13 0x0041e82d in Perl_call_sv () > > #14 0x2b66ec9ee038 in XS_DBI_dispatch () from > > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so > > #15 0x0046bc47 in Perl_pp_entersub () > > #16 0x0046a29e in Perl_runops_standard () > > #17 0x0041f1d1 in perl_run () > > #18 0x0041ba2c in main () > > > > > > > > *** glibc detected *** /usr/local/bin/perl: double free or corruption > > (!prev): 0x01163e10 *** > > === Backtrace: = > > /lib64/libc.so.6[0x2ad39584e34e] > > /lib64/libc.so.6(__libc_free+0x6c)[0x2ad39584f95c] > > /us
Re: Need help with aggregate functions and queries that return zero records
Thanks for the hint, Jeff. Your suggestion worked!
- Ashok
On Tue, Mar 4, 2008 at 5:53 PM, Jeff Zucker <[EMAIL PROTECTED]> wrote:
> Hi Ashok,
>
> MJD also found that bug. I've fixed it but not uploaded the new version
> yet because I'm fixing a couple of other things. You can apply this
> patch yourself if you need it soon:
>
> Changing line 1189 of SQL/Statement.pm like so fixes it:
>
> - $rows = $g->calc;
> + $rows = $g->calc || [];
>
> Sorry for the problems.
>
> --
> Jeff
>
> Ashok Vemuri wrote:
> > Hi,
> >
> > I am having a bit of trouble using aggregate functions with DBI::CSV
> > (version 0.22) and could use some help figuring out why.
> >
> > I have the following code snippet that queries a CSV file named
> > "masterdata", located at c:/test/output folder.
> >
> >
> > use DBI;
> >
> > my $dbh = DBI->connect("DBI:CSV:f_dir=c:/test/output")
> > or die "Cannot connect: " . $DBI::errstr();
> >
> > my $sth = $dbh->prepare("SELECT callingPartyUnicodeLoginUserID as user,
> > count(duration) as calls, sum(duration) as duration FROM cmasterdata
> WHERE
> > dateTimeOrigination > 1201979253 AND callingPartyUnicodeLoginUserID not
> like
> > '' group by callingPartyUnicodeLoginUserID order by calls desc")
> > or die "Cannot prepare: " . $dbh->errstr();
> >
> > eval {
> > $sth->execute();
> > }
> >
> > if ($@) {
> > print "error: [EMAIL PROTECTED]";
> > }
> >
> > =
> >
> > The execute() statement above fails with the following error message
> when
> > there are no matching records in the CSV file.
> >
> > DBD::CSV::st execute failed: Can't use an undefined value as an ARRAY
> > reference at C:/MYINST~1/objects/perl/ActivePerl-
> > 5.8.8.822-MSWin32-x86-280952/site/lib/SQL/Statement.pm line 1197,
> > line 242.
> > [for Statement "SELECT callingPartyUnicodeLoginUserID as
> > users,count(duration)as calls,sum(duration) as duration FROM masterdata
> > WHERE dateTimeOrigination > 1201991649 AND
> callingPartyUnicodeLoginUserID
> > not like '' group by callingPartyUnicodeLoginUserID order by calls
> desc"]
> >
> >
> > However, the code runs fine (on the same CSV file) if I remove aggregate
> > functions from the query. For example, the following query is fine:
> >
> > SELECT callingPartyUnicodeLoginUserID as user, dateTimeOrigination as
> > datetime FROM cmasterdata WHERE dateTimeOrigination > 1201979253 AND
> > callingPartyUnicodeLoginUserID not like ''
> >
> > Is there a known issue with DBD::CSV where trying aggregate functions
> when
> > no matching records gives an error, or am I just doing something wrong
> here?
> >
> >
> > TIA,
> > Ashok
> >
> >
>
>
Re: DBD::Oracle - execute_array core dumps intermittently
Should have posted to users not dev. This is really a bizarre problem. I can get it to fail about every fifth iteration otherwise the process works. I ran it from another server connect to the same database and it will intermittently fail. I run it from a third sever and I can't get it to core dump. All 3 servers have the same kernel & Perl versions. I've tried recompiling Perl, DBI, DBD::Oracle, still no luck. I created a test case, which uses execute_array and of course I can't get it to core dump. If anyone has any ideas on what might be going on here, I would love to hear them! Thanks STH On Wed, 2008-03-05 at 15:21 -0600, Scott T. Hildreth wrote: > I am not sure how to describe this, my co-worker will run his process and get > a core dump > (I pasted the back trace below) and then run the process again with no core > dumps. Sometimes > it will core dump several times in a row and then the next run it finishes > fine. I ran the process > with DBI_TRACE=9 and this is what shows up at the end of the log, > > > 1 -> execute_for_fetch for DBD::Oracle::st (DBI::st=HASH(0xN)~INNER > CODE(0xN) undef) > ora_st_execute_array UPDATE count=10 (ARRAY(0xN) undef undef)... > > OCIBindByName(112df38,1132188,10a9138,":p1",placeh_len=3,value_p=0,value_sz=-1517274788,dty=1,indp=0,alenp=0,rcodep=0,maxarr_len=0,curelep=0 > (*=0),mode=2)=ERROR > OCIErrorGet(10a9138,1,"",7fff058d684c,"ORA-02005: implicit (-1) > length not valid for this bind or define datatype > ",1024,2)=SUCCESS > OCIErrorGet after OCIBindByName (er1:ok): -1, 2005: ORA-02005: implicit > (-1) length not valid for this bind or define datatype > > OCIErrorGet(10a9138,2,"",7fff058d684c,"ORA-02005: implicit (-1) > length not valid for this bind or define datatype > ",1024,2)=NO_DATA > > At first I thought it was a 32bit library with a 64bit Perl problem, but > Oracle.so & Perl are both linked > with the correct 64 bit libs. The Oracle client is 10.2.0.3 and DBI versions > are, > > Perl: 5.008008(x86_64-linux) > OS : linux (2.6.20.19) > DBI : 1.602 > DBD::mysql : 4.005 > DBD::Sponge : 12.010002 > DBD::SQLite : 1.13 > DBD::Proxy : 0.2004 > DBD::Oracle : 1.20 > DBD::Multiplex : 2.04 > DBD::Gofer : 0.010103 > DBD::File : 0.35 > DBD::ExampleP : 12.010007 > DBD::DBM: 0.03 > > I am going to try to isolate a small test case, but right now I wanted to > post what I > have found so far. > > Thanks, >STH > > ## Back Trace > # > > (gdb) bt > #0 0x2b66ec7d9b95 in raise () from /lib64/libc.so.6 > #1 0x2b66ec7daf90 in abort () from /lib64/libc.so.6 > #2 0x2b66ec81035b in __libc_message () from /lib64/libc.so.6 > #3 0x2b66ec81534e in malloc_printerr () from /lib64/libc.so.6 > #4 0x2b66ec81695c in free () from /lib64/libc.so.6 > #5 0x2b66ef0ac102 in ora_st_execute_array () from > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so > #6 0x2b66ef0a62bf in XS_DBD__Oracle__st_ora_execute_array () >from > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so > #7 0x0046bc47 in Perl_pp_entersub () > #8 0x0046a29e in Perl_runops_standard () > #9 0x0041e82d in Perl_call_sv () > #10 0x2b66ec9ee038 in XS_DBI_dispatch () from > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so > #11 0x0046bc47 in Perl_pp_entersub () > #12 0x0046a29e in Perl_runops_standard () > #13 0x0041e82d in Perl_call_sv () > #14 0x2b66ec9ee038 in XS_DBI_dispatch () from > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so > #15 0x0046bc47 in Perl_pp_entersub () > #16 0x0046a29e in Perl_runops_standard () > #17 0x0041f1d1 in perl_run () > #18 0x0041ba2c in main () > > > > *** glibc detected *** /usr/local/bin/perl: double free or corruption > (!prev): 0x01163e10 *** > === Backtrace: = > /lib64/libc.so.6[0x2ad39584e34e] > /lib64/libc.so.6(__libc_free+0x6c)[0x2ad39584f95c] > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so(ora_st_execute_array+0xfa4)[0x2ad3980e6e94] > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBD/Oracle/Oracle.so(XS_DBD__Oracle__st_ora_execute_array+0xef)[0x2ad3980e0f9f] > /usr/local/bin/perl(Perl_pp_entersub+0x6b7)[0x46bae7] > /usr/local/bin/perl(Perl_runops_standard+0xe)[0x46a13e] > /usr/local/bin/perl(Perl_call_sv+0x49d)[0x41e80d] > /usr/local/perl-5.8.8/lib/site_perl/5.8.8/x86_64-linux/auto/DBI/DBI.so(XS_DBI_dispatch+0x7a8)[0x2ad395a27068] > /u
