Bug #15198 Updated: unexpected error 'OCI8 Recursive call!'
| From: | smkelly at rooster dot creighton dot edu | Date: | Thu, 28 Feb 2002 18:31:41 +0000 |
| Subject: | Bug #15198 Updated: unexpected error 'OCI8 Recursive call!' | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-1311@lists.php.net to get a copy of this message | ||
ID: 15198
Updated by: smkelly@rooster.creighton.edu
Reported By: ivo@ibuildings.nl
Status: Analyzed
Bug Type: OCI8 related
Operating System: Redhat Linux 6.1
PHP Version: 4.1.1
Assigned To: thies
New Comment:
I've also got a PHP application that suffered from the OCI8 Recursive
call! error after an upgrade to PHP 4.1.1. It worked fine with PHP
4.0.x, but with 4.1.x it randomly chokes with that error. There is
nothing special going on. I'm not using bindings, I've just got
scripts that logon, parse, execute, insert, delete, logoff, etc.
Because of this, I'm forced to stick with the 4.0.x tree. I'd give you
more debugging information, but it is a deployed system and I don't
want to introduce the bugs into it.
Previous Comments:
------------------------------------------------------------------------
[2002-02-05 05:07:25] thies@php.net
are you sure that you are not hitting the time_limit?
reverting to 4.0.6 is not a smartthimg (tm) to do as a recursive oci
call might kill your oracle MTS (if you
use it). that's the only reason this catch got implemented.
maybe useing ociinternaldebug(1) and sending me the output (and just
the output of the oci module) would
help.
------------------------------------------------------------------------
[2002-02-05 03:30:24] ivo@ibuildings.nl
Well, I have investigated the situation a bit more:
I have a script which takes a long time (a maintenance script that runs
at night, using php cgi binary), so I have set set_time_limit(7200)
(which is two hours!)
In the script, there's a complex query that takes 3 minutes to run.
During this query, I get this OCI8 Recursive Call error and the script
fails, even though the time limit has not been reached yet. Is there
some internal timeout in the OCI calls? I now have to downgrade to
4.0.6 to prevent the problem.
------------------------------------------------------------------------
[2002-01-25 10:40:07] thies@php.net
this happens when an oci-call gets interrupted by a signal. this should
only happen in 2 stituations:
- you script hits max_execution_time (bad)
- you did an apachectrl restart instead of apachectrl graceful
the message "recursive call" is consitered a fatal-error and the apache
child that generated that message will be terminated by the php
oci-driveri. this is cause i've seen oracle MTS servers crashing when a
client tried to call the oci* stuff in a reentrant way. i currently
know no better way to save my "unbreakable" oracle from crashing;-)
------------------------------------------------------------------------
[2002-01-25 10:39:26] thies@php.net
this happens when an oci-call gets interrupted by a signal. this should
only happen in 2 stituations:
- you script hits max_execution_time (bad)
- you did an apachectrl restart instead of apachectrl graceful
the message "recursive call" is consitered a fatal-error and the apache
child that generated that message will be terminated by the php
oci-driveri. this is cause i've seen oracle MTS servers crashing when a
client tried to call the oci* stuff in a reentrant way. i currently
know no better way to save my "unbreakable" oracle from crashing;-)
------------------------------------------------------------------------
[2002-01-24 04:44:03] ivo@ibuildings.nl
I have a script that does an OCILogin, then OCIParses a query, then
does a few OCIBindByName calls, an OCIExecute, an OCIFreeStatement and
finally OCILogoff.
The query is a PL/SQL block with a BEGIN, a few update and insert
queries and an END.
Most of the time the script runs fine. But every now and then (haven't
discovered any regularity yet) I'm getting 'OCI8 Recursive call!' in my
error logs.
I've taken a look at ext/oci8/oci8.c to see what would trigger this
error, and from what I see there, I can think of no errors in my script
that could cause this. So my guess os that it is some internal error.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=15198&edit=1