Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy
Actually, I did exactly this a few years ago. Only problem: NULLs show up as blanks ... Apart from that, it works like a charm! -- Peter Vanroose. Op 23 jun. 2020 22:10, om 22:10, "Fennell, Brian" schreef: >Another idea . . . > >You could also wrap Oracle SQLPlus in perl using qx > >How-to SQLPLUS and XML here: > >https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3512822500346787661 > >That and a little perl text parsing could get you a long way - split , >grep, map, s and tr. > >This pure-perl module can parse the XML: >https://metacpan.org/pod/XML::SAX::PurePerl > >It would be great to have an Oracle DBD driver using pure-perl and >sqlplus only. No C complier needed, no buffer overflows to chase >down, no jvm and no "other" languages (except SQL). > >(no time for this kind of perl-uber-hacking myself but anyone looking >for a fun project . . . ) > >Another hack is to use perl with qx with jisql (and JDBC drivers) - I >have used this to access Microsoft SQLServer from perl with little >work. > >https://github.com/stdunbar/jisql > >Brian Fennell > > > > >The information contained in this electronic mail transmission is >intended only for the use of the individual or entity named in this >transmission. If you are not the intended recipient of this >transmission, you are hereby notified that any disclosure, copying or >distribution of the contents of this transmission is strictly >prohibited and that you should delete the contents of this transmission >from your system immediately. Any comments or statements contained in >this transmission do not necessarily reflect the views or position of >Radial or its subsidiaries and/or affiliates.
Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy
Another idea . . . You could also wrap Oracle SQLPlus in perl using qx How-to SQLPLUS and XML here: https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3512822500346787661 That and a little perl text parsing could get you a long way - split , grep, map, s and tr. This pure-perl module can parse the XML: https://metacpan.org/pod/XML::SAX::PurePerl It would be great to have an Oracle DBD driver using pure-perl and sqlplus only. No C complier needed, no buffer overflows to chase down, no jvm and no "other" languages (except SQL). (no time for this kind of perl-uber-hacking myself but anyone looking for a fun project . . . ) Another hack is to use perl with qx with jisql (and JDBC drivers) - I have used this to access Microsoft SQLServer from perl with little work. https://github.com/stdunbar/jisql Brian Fennell The information contained in this electronic mail transmission is intended only for the use of the individual or entity named in this transmission. If you are not the intended recipient of this transmission, you are hereby notified that any disclosure, copying or distribution of the contents of this transmission is strictly prohibited and that you should delete the contents of this transmission from your system immediately. Any comments or statements contained in this transmission do not necessarily reflect the views or position of Radial or its subsidiaries and/or affiliates.
RE: [EXTERNAL] Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy
FYI The Oracle DBD driver is hard to build, it requires Oracle C Libraries and Header files. It also requires Oracle Development files described by Oracle as Examples, but which are really templates for building any C client. All Oracle C Clients are hard to build. If I recall sometimes a library has to be included on the compiler / linker command line three times because of circular references of one library to another which cannot be resolved on one pass. Ambiguity in wide characters "bytes per character" can make for buffer overflows which require a lot of time to hunt down and fix. Even if you are not using wide characters. The CPAN version of the DBD driver (the last time I checked) is abandonware - someone keeps a patched fork on GIT. You can use cpanm (cpanminus) to build directly from git but not cpan. Docs in the cpanm man page. Lost mindshare from Perl to python and ruby have contributed to the problem remaining unresolved (all bugs are shallow given enough eyeballs - this doesn't work so well when the number of eyeballs drops greatly).I ended up downgrading both perl 5 and Oracle DBD to workaround a problem we had with a Perl/Oracle bug causing buffer overflows and seg-faults. I just couldn't afford the hours to fix it properly. Perl 5 internal structures had changed so much that older (working) versions of DBD no longer compiled against newer perl 5s. One workaround it to consider using the perl JDBC driver to access the Oracle JDBC library instead of trying to get the Oracle C Library to compile bug-free. You will need to bootstrap a jvm with the bridge in order to use it. Calling out from perl to a python "select to CSV" or "select to xml" or "select to JSON" might be another work-around - depending on your requirements - might be faster than booting up a JVM. Just my experience. The information contained in this electronic mail transmission is intended only for the use of the individual or entity named in this transmission. If you are not the intended recipient of this transmission, you are hereby notified that any disclosure, copying or distribution of the contents of this transmission is strictly prohibited and that you should delete the contents of this transmission from your system immediately. Any comments or statements contained in this transmission do not necessarily reflect the views or position of Radial or its subsidiaries and/or affiliates.
Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy
> On Jun 19, 2020, at 3:48 PM, Scott wrote: > > We have run into an issue when we upgraded to Oracle client 19c. Some of the > users processes are segfaulting on exit. > > #0 0x7f82ee84ccc0 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #1 0x7f82e6444f43 in kputxabt () from > /u01/app/oracle/product/19.3.0.0/lib/libclntsh.so.19.1 > #2 0x7f82e926e6c3 in ora_db_rollback () from > /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so > #3 0x7f82e9266b11 in XS_DBD__Oracle__db_DESTROY () from > /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so > #4 0x7f82ed10291d in XS_DBI_dispatch () from > /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so > > I tested the same process on a server still using the 18c client and the > core dump does not happen. Our DBA is creating > ticket with Oracle, but I wanted to see if anyone else has had the same issue. I am not seeing this issue with the 19C instant client ( 19.6 ) running on CentOS8, DBD::Oracle 1.80, DBI 1.643. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs
Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy
On 6/20/20 1:51 PM, Scott wrote:
More info, this error does not occur with DBD::Oracle 1.76.
DBD::Oracle 1.80 => works with 18c client, but fails with 19c.
DBD::Oracle 1.76 => works with all client versions.
On 6/19/20 5:48 PM, Scott wrote:
We have run into an issue when we upgraded to Oracle client 19c. Some
of the users processes are segfaulting on exit.
#0 0x7f82ee84ccc0 in pthread_mutex_lock () from
/lib64/libpthread.so.0
#1 0x7f82e6444f43 in kputxabt () from
/u01/app/oracle/product/19.3.0.0/lib/libclntsh.so.19.1
#2 0x7f82e926e6c3 in ora_db_rollback () from
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#3 0x7f82e9266b11 in XS_DBD__Oracle__db_DESTROY () from
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so
#4 0x7f82ed10291d in XS_DBI_dispatch () from
/usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so
I tested the same process on a server still using the 18c client and
the core dump does not happen. Our DBA is creating
ticket with Oracle, but I wanted to see if anyone else has had the
same issue.
Thanks,
Scott
I assuming this is the change causing the segfault with 19c client.
Destroy envhp with last dbh (GH#93, GH#89, Dean Hamstead, CarstenGrohmann)
diff -w ../DBD-Oracle-1.76/dbdimp.c ./dbdimp.c 1
218,222d217
< if (imp_drh->envhp) {
< /* Free cached environment handle. */
< OCIHandleFree_log_stat(imp_drh, imp_drh->envhp,
OCI_HTYPE_ENV, status);
< }
<
319c314
< case ORA_XMLTYPE: /* SQLT_NTY must be carefull
here as its value (108) is the same for an embedded object Well realy
only XML clobs not embedded objects */
---
> case ORA_XMLTYPE: /* SQLT_NTY must be careful
here as its value (108) is the same for an embedded object Well really
only XML clobs not embedded objects */
863c858
< session_pool_t pool_data = { };
---
> session_pool_t pool_data = {0};
1258a1254
> /* free session environment handle */
1260a1257,1266
> if ( status == OCI_SUCCESS ) {
> imp_dbh->envhp = NULL;
> }
> /* free global environment handle during
destruction of last connection */
> } else if ( (imp_dbh->envhp == imp_drh->envhp)
&& (SvTRUE(perl_get_sv("DBI::PERL_ENDING",0))) ) {
> OCIHandleFree_log_stat(imp_dbh, imp_dbh->envhp, OCI_HTYPE_ENV, status);
> if ( status == OCI_SUCCESS ) {
> imp_dbh->envhp = NULL;
> imp_drh->envhp = NULL;
> }
3739c3745
< as we may have more thatn one exe on a prepare*/
---
> as we may have more than one exe on a prepare*/
4779c4785
< bool can_taf = 0;
---
> boolean can_taf = 0;
Re: DBD::Oracle 1.80 & Oracle client 19c Segfaults on Destroy
More info, this error does not occur with DBD::Oracle 1.76. DBD::Oracle 1.80 => works with 18c client, but fails with 19c. DBD::Oracle 1.76 => works with all client versions. On 6/19/20 5:48 PM, Scott wrote: We have run into an issue when we upgraded to Oracle client 19c. Some of the users processes are segfaulting on exit. #0 0x7f82ee84ccc0 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x7f82e6444f43 in kputxabt () from /u01/app/oracle/product/19.3.0.0/lib/libclntsh.so.19.1 #2 0x7f82e926e6c3 in ora_db_rollback () from /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so #3 0x7f82e9266b11 in XS_DBD__Oracle__db_DESTROY () from /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBD/Oracle/Oracle.so #4 0x7f82ed10291d in XS_DBI_dispatch () from /usr/local/perl-5.22.0-thr/lib/site_perl/5.22.0/x86_64-linux-thread-multi/auto/DBI/DBI.so I tested the same process on a server still using the 18c client and the core dump does not happen. Our DBA is creating ticket with Oracle, but I wanted to see if anyone else has had the same issue. Thanks, Scott
