Try doing the disconnect inside the signal handler.
But be aware that doing _anything_ in perl inside an asynchronous
signal handler is prone to problems.
Also be aware that signal handling has changed in perl 5.8 and
you may well find you have a different set of problems then.
Tim.
On Wed, Oct 23, 2002 at 04:54:25PM +1000, Mike McCauley wrote:
> Hi Folks.
>
> Im seeing some nasty behaviour from DBD-Oracle with Oracle 9i that causes the
> client to exit and core-dump with an Oracle internal error.
>
> Below is a very simple program that illustrates the program. It connects to a
> database (any Ora database will do, doesnt need any tables), then runs a
> simple do query loop forever. OK so far, works fine. There is a conventional
> exec/timeout around the do to catch network and server problems. If a timeout
> occurs it disconnects from the database, but.... that causes an ORA internal
> error, core dump and exit.
>
> ORA reports something that looks like it complaining about a recursive
> function call, even though the timed-out call was subsequently cancelled.
>
> I suspect this is a Oracle bug, or maybe DBD-Oracle not driving Oracle quite
> correctly. Can anyone confirm? Can anyone think of a workaround? Crashing in
> the disconnect is causing lots of grief, and its not an option not to
> disconnect. I dont think it happened with Ora 8.
>
> Tried doing $sth->cancel in the timeout and elsewhere. Cancel runs OK but
> doesnt make any difference to the internal error.
>
> Relevant info:
> DBI-1.20 or 1.30
> DBD-Oracle-1.12
> perl 5.6.1
> Red Hat 7.3 Intel
> Oracle 9i (9.0.1) for Linux.
>
> Heres the program:
>
> # Illustrates a problem with DBD Oracle 9i.
> # A timeout in an execute, followed by a
> # disconnect causes oracle internal error
> # with DBI-1.20 or 1.30, DBD-Oracle-1.12, perl 5.6.1, Red Hat 7.3 Intel
> # Run this for a few secs, then unplug from the network.
> # the execute times out,tries
> # to disconnect, get internal error
> use DBI;
>
> # Change to suit your system:
> my $dbsource =
>
>'dbi:Oracle:(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=oscar.open.com.au)(PORT=1521))(CONNECT_DATA=(SID=osc)))';
> my $dbuser = 'system';
> my $dbauth = 'manager';
> my $timeout = 2; # seconds
>
> my $dbh = DBI->connect($dbsource, $dbuser, $dbauth) || die $DBI::errstr;
> #DBI->trace(3);
>
> while (1)
> {
> my $sth;
> # Conventional timeout handling as recommended by DBI.pm
> eval
> {
> # Makes no difference if you cancel in here or not. If run, it
> # returns 1, indicating the Oracle cancel really got run.
> local $SIG{ALRM} = sub {my $res;
> $sth && ($res = $sth->cancel());
> print "sigalrm $res\n";
> die "timeout"};
> alarm($timeout);
> # The exact contents of the query make no difference
> $sth = $dbh->prepare("begin dbms_output.enable(1000); end;");
> $sth && $sth->execute();
> };
> alarm(0);
> if ($@)
> {
> # There was a timeout:
> print "about to disconnect\n";
> # internal error and oracle core dump in here:
> $dbh->disconnect();
> exit;
> }
> print "done $sth\n";
> sleep 1;
> }
> # end
>
> If you run it for a few seconds, then disconnect the network between the
> client and the server for a few seconds, you see this:
>
> done DBI::st=HASH(0x8206a70)
> done DBI::st=HASH(0x8206bb4)
> done DBI::st=HASH(0x8206b18)
> done DBI::st=HASH(0x8180974)
> done DBI::st=HASH(0x8206aa0)
> done DBI::st=HASH(0x8206a70)
> sigalrm 1
> about to disconnect
> OCI-21500: internal error code, arguments: [ttcdrv-recursivecall], [], [], [],
> [
> ], [], [], []
> Errors in file :
> OCI-21500: internal error code, arguments: [ttcdrv-recursivecall], [], [], [],
> [
> ], [], [], []
>
>
> ----- Call Stack Trace -----
> Cannot open /proc/15214/exe.
> calling call entry argument values in hex
> location type point (? means dubious value)
> -------------------- -------- --------------------
> ----------------------------
> Cannot find symbol in /proc/15214/exe.
> Cannot find symbol in /proc/15214/exe.
> Cannot find symbol in /proc/15214/exe.
> Cannot find symbol in /proc/15214/exe.
> Cannot find symbol in /proc/15214/exe.
> Cannot find symbol in /proc/15214/exe.
> Cannot find symbol in /proc/15214/exe.
> Cannot find symbol in /proc/15214/exe.
> 402ECDEB CALL 401987A4 BFFFADE0 ? 402ECDAD ?
> 40825004 ? 40803AA0 ?
> 820DAC8 ? 82039A0 ?
> 4069463A CALLr 00000000 820D9EC ? 820D9EC ?
> BFFFB268 ? 4000B230 ?
> 821B3C4 ? 821CFBC ?
> 4051584C CALL 40185104 405156B0 ? 4213030C ? 0 ?
> 407F2774 ?
> 403EF756 CALLr 00000000 821CFBC ? 4050746C ?
> 40825004 ? BFFFB888 ?
> 4027EE24 CALLr 00000000 821CFBC ? BFFFB300 ?
> 40825004 ? 0 ? 9 ? 4024F0C4
> ?
> 4027E786 CALL 4018E604 0 ? 0 ? 0 ? 0 ? 0 ?
> 4027E6D1 ?
> 40274AC5 CALL 40192D14 821ADF0 ? 821B4D4 ?
> 40274A90 ? 81F4958 ?
> BFFFF408 ? 401D259F ?
> 401D259A CALL 40186A74 821AE5C ? 81F0E5C ? 81F3464
> ?
> 81F0DD8 ?
> 402633D4 CALL 40198C54 313 ? 821ADF0 ? 402633B0 ?
> 81F4620 ? BFFFF468 ?
> 400DBC9E ?
> 400DBC99 CALL 400D79D0 80FD208 ? 400EB2DC ?
> 817DC80 ? 8180938 ?
> BFFFF4A8 ? 400D83D7 ?
> 400D83D2 CALL 400D75A0 80FD208 ? 1 ? 80FB7A0 ?
> 80FB7C0 ?
> 400CA455 CALLr 00000000 80 ? 8095B70 ? E ? E ?
> BFFFF618 ? 80907E3 ?
> Perl_pp_entersub CALLr 00000000 0 ? 4ED7FEA8 ? 8167418 ?
> 80803 ? A ? 80FD210 ?
> Perl_runops_standar CALLr 00000000 BFFFF7A8 ? 805C04B ? 1 ? 1
> ?
> BFFFF6F8 ? 1 ?
> S_run_body()+193 CALLs 00000000
> perl_run()+134 CALL S_run_body()+0 0 ? 1 ? 80FB3E0 ? 80FB9A0 ?
> main()+108 CALL perl_run()+0 BFFFF808 ? 42017499 ? 2 ?
> BFFFF834 ? BFFFF840 ?
>
> .................
>
>
>
> --
> Mike McCauley [EMAIL PROTECTED]
> Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
> 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
> Phone +61 3 9598-0985 Fax +61 3 9598-0955
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS etc on Unix, Windows, MacOS etc.
>
