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.
