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.