The failure you are getting in plsql.t is a known problem between DBI 1.15
and DBD::Oracle's ORA_RSET return handling. If you don't need to return
cursors from PL/SQL, ignore the error and install, otherwise drop back to
DBI 1.14.
--
Mac :})
** I normally forward private database questions to the DBI mail lists. **
Give a hobbit a fish and he'll eat fish for a day.
Give a hobbit a ring and he'll eat fish for an age.
----- Original Message -----
From: "Peter Scott" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, May 18, 2001 09:53
Subject: Core dump in plsql.t on Solaris
> No matter what I have tried so far, I get a core dump in test 55 of
plsql.t.
>
> I'm on Solaris 2.5.1 with perl 5.6.1, DBI 1.15, and Oracle 7.2.2. I've
> tried a plain make, and a make with the suggested -b, -c, -l, and -n
> LIBCLNTSH, all result in:
>
> t/plsql.............dubious
> Test returned status 0 (wstat 139, 0x8b)
> test program seems to have generated a core
> DIED. FAILED tests 55-63
>
> Building with -g doesn't seem to help with gdb on the core:
>
> Program terminated with signal 11, Segmentation fault.
> "/usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1": not in executable format:
> File format not recognized.
> #0 0xef554f04 in _end ()
>
> Building with -p causes it to fail worse:
>
> t/general...........install_driver(Oracle) failed: Can't load
> 'blib/arch/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: ld.so.1:
> /opt/perlnew/bin/perl: fatal: libclntsh.so.1.0: can't open file: errno=2
at
> /opt/perlnew/lib/5.6.1/sun4-solaris-2.5.1/DynaLoader.pm line 206.
> at (eval 1) line 3
> Compilation failed in require at (eval 1) line 3.
> Perhaps a required shared library or dll isn't installed where expected
>
> The core dump happens at the last line of this part of plsql.t:
>
> my $cur_query = q{
> SELECT object_name, owner FROM all_objects
> WHERE object_name LIKE :p1 and ROWNUM <= 3
> };
> my $cur1 = 42;
> #$dbh->trace(4);
> my $parent = $dbh->prepare(qq{
> BEGIN OPEN :cur1 FOR $cur_query; END;
> });
> ok(0, $parent);
> ok(0, $parent->bind_param(":p1", "V%"));
> ok(0, $parent->bind_param_inout(":cur1", \$cur1, 0, { ora_type =>
> ORA_RSET } ));
> ok(0, $parent->execute());
>
> BTW, I don't even understand that SQL, so maybe I can get by without it
> working :-)
>
> I've stepped through the test in the debugger and everything seems okay
> until the call to _setup_handle:
>
> 696==> DBI::_setup_handle($h, $imp_class, $parent, $imp_data);
> 697
> 698: return $h unless wantarray;
> 699: ($h, $i);
> 700 }
> 701 # minimum constructors for the tie's (alias to XS version)
> 702: sub DBI::st::TIEHASH { bless $_[1] => $_[0] };
>
> At this point, a single step takes me to Carp::longmess with a @_ of
> 'SIGSEGV'. If instead I look at $h, I see this:
>
> DB<3> x $h
> 0 DBI::st=HASH(0x5862dc)
> SV = PVMG(0x586df8) at 0x587c40
> REFCNT = 1
> FLAGS = (ROK)
> IV = 0
> NV = 0
> RV = 0x532dc4
> dbih_getcom handle 'DBI::st=HASH(0x532dc4)' is not a DBI handle (has no
> magic) at /opt/perlnew/lib/5.6.1/dumpvar.pl line 154.
> SV = PVMG(0x586df8) at 0x587c40
> REFCNT = 1
> FLAGS = (ROK)
> IV = 0
> NV = 0
> RV = 0x532dc4
> SV = RV(0x3e1828) at 0xefffeed8
> REFCNT = 1
> FLAGS = (ROK,READONLY)
> RV = 0x532dc4
> Issuing rollback() for database handle being DESTROY'd without explicit
> disconnect() at /opt/perlnew/lib/5.6.1/perl5db.pl line 1483.
> Debugged program terminated.
>
> Well, that can't be right.
>
> FWIW, I've been using these Oracle libraries successfully on Solaris 2.5.1
> with perl 5.004_04 and a DBI of 0.89 and DBD::Oracle of 0.46 (don't
laugh).
>
> Any ideas? This is the only test that fails - well, I don't know what the
> remaining 7 subtests would do, obviously.
>
> Yeah, yeah, 7.2.2 is old. My next step is to essay 8.1.6 on Solaris
> 2.6. But I still need something working on Solaris 2.5.1, and Oracle
8.1.6
> is not supported there.
