Well it will be in either one of two .c files dbdimp.c or oci8.c The XS side of things Oracle.xs is not used very much.
The level 15 debug will get deep inside the c to see where it is happening. The trace you gave is a little high level you are right ORA-01403 dose not make much sense here. If could be running out of buffer. Give some of the caching params a tweak https://metacpan.org/pod/DBD::Oracle#RowCacheSize if you can try give fetchrow_hashref a try as see if the error happens there as well. Cheers John DBD::Oracle - Oracle database driver for the DBI module ...<https://metacpan.org/pod/DBD::Oracle#RowCacheSize> metacpan.org Oracle database driver for the DBI module ... NAME; VERSION; SYNOPSIS; DESCRIPTION; CONSTANTS; DBI CLASS METHODS. connect. OS authentication ________________________________ From: Fennell, Brian <fenne...@radial.com> Sent: December 18, 2017 11:25 AM To: John Scoles; dbi-users@perl.org Subject: RE: Hunting down (possible) memory leak in DBD::Oracle John, Thanks so much for your reply! I have put off this work for a few years and now the pressure is on - the original box and OS are so old that the DBA and System Engineer and the Operations manager have all ganged up on me. I suppose I could try and work around by downgrading both the perl and the DBD::Oracle to the same version we use in production, but it would be nice to actually fix the bug if I can. I tried just downgrading the DBD::Oracle, but changes in perl 5 to support MULTIPLICITY made that look like more than just a little work - spend two days on it and then backed off. I am a polyglot programmer so I can program in C and Perl (and about a dozen other languages). I have done enough time with C that it doesn't scare me. Valgrind is new to me, but make and gcc and ld are not. I have started to read the Valgrind docs and it seems to make sense - it basically emulates all the CPU instructions with injected instrumentation - I assume it works for Intel and Red Hat if it works at all (and it seems to have a long history and good open source support community). Perhaps I am fooling myself, but I figure it is worth a try. I have negotiated support from both DBA and System Engineering (the Red Hat OS guys) so if I am going to fix this now is the time. The only other option I can think of is to try to get the old code working with the DBD::JDBC driver (which would mean adding a JVM running in parallel and additional overhead - so I would rather not). 1) The error changes depending on the data - which is why I think it is a buffer overrun or a wild pointer - but it is always in "field N of N" - Current I can reproduce with ORA-01403 2) I will re-try at level 15 and post the results - current at 4 (or perhaps 5) here is a section from the log (which suggests to me it is happing in the C code and not in the Perl -> fetchrow_array for DBD::Oracle::st (GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010 dbd_st_fetch 6 fields... dbd_st_fetched 6 fields with status of 0(SUCCESS) field #1 with rc=0(OK) field #2 with rc=0(OK) field #3 with rc=0(OK) field #4 with rc=1405(NULL) field #5 with rc=0(OK) field #6 with rc=0(OK) -> fetchrow_array for DBD::Oracle::st (GSI::DBI::Connection::st=HASH(0x29353c8)~0x286f6b0) thr#134c010 dbd_st_fetch 6 fields... dbd_st_fetched 6 fields with status of 0(SUCCESS) field #1 with rc=0(OK) field #2 with rc=0(OK) field #3 with rc=0(OK) field #4 with rc=14135(UNKNOWN RC=14135)) OCIErrorGet after ORA-14135 error on field 4 of 6, ora_type 2 (er1:ok): -1, 1403: ORA-01403: no data found -- HandleSetErr err=1403, errstr='ORA-01403: no data found (DBD ERROR: ORA-14135 error on field 4 of 6, ora_type 2)', state=undef, undef field #5 with rc=0(OK) field #6 with rc=0(OK) 1 -> FETCH for DBD::Oracle::st (GSI::DBI::Connection::st=HASH(0x286f6b0)~INNER 'ParamValues') thr#134c010 3) I think the most exotic thing in these tables is a VARCHAR2 but I will check and post the results. 4) I looks like it is in the XS to me (see answer to 2) - but I suppose it could be elsewhere - like a loopback-perl-ref that should be weak but is not. 5) I think I have what I need, DBA installed Oracle 12 OCI client and "dot.so" libraries but currently I am concerned that I am using "ins_rdbms.mk" when I should be using "demo.mk" or similar - I am getting a Warning (see details below) when I run Makefile.PL - I asked DBA to look into installing the "demo.mk" file and consider opening up a Oracle METALINK support ticket to see if another customer had already solved this with Oracle's help. Details: # /usr/local/bin/perl Makefile.PL -g Using DBI 1.637 (for perl 5.016003 on x86_64-linux-thread-multi) installed in /usr/local/lib64/perl5/auto/DBI/ Configuring DBD::Oracle for perl 5.016003 on linux (x86_64-linux-thread-multi) Remember to actually *READ* the README file! Especially if you have any problems. Installing on a linux, Ver#3.10 Using Oracle in /db/app/oracle/product/12.1.0/client_1 DEFINE _SQLPLUS_RELEASE = "1201000200" (CHAR) Oracle version 12.1.0.2 (12.1) Found /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk Using /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk Your LD_LIBRARY_PATH env var is set to '/db/app/oracle/product/12.1.0/client_1/lib:/db/app/oracle/product/12.1.0/client_1' Reading /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk Reading /db/app/oracle/product/12.1.0/client_1/rdbms/lib/env_rdbms.mk WARNING: Oracle /db/app/oracle/product/12.1.0/client_1/rdbms/lib/ins_rdbms.mk doesn't define a 'build' rule. WARNING: I will now try to guess how to build and link DBD::Oracle for you. This kind of guess work is very error prone and Oracle-version sensitive. It is possible that it won't be supported in future versions of DBD::Oracle. *PLEASE* notify dbi-users about exactly _why_ you had to build it this way.
