php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15198 unexpected error 'OCI8 Recursive call!'
Submitted: 2002-01-24 04:44 UTC Modified: 2003-05-18 11:52 UTC
Votes:17
Avg. Score:4.4 ± 0.8
Reproduced:16 of 16 (100.0%)
Same Version:4 (25.0%)
Same OS:3 (18.8%)
From: ivo at ibuildings dot nl Assigned: thies (profile)
Status: No Feedback Package: OCI8 related
PHP Version: 4.1.1 OS: Redhat Linux 6.1
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: ivo at ibuildings dot nl
New email:
PHP Version: OS:

 

 [2002-01-24 04:44 UTC] ivo at ibuildings dot 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-01-25 10:39 UTC] 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:40 UTC] 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-02-05 03:30 UTC] ivo at ibuildings dot 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-02-05 05:07 UTC] 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-28 13:31 UTC] smkelly at rooster dot creighton dot edu
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.
 [2002-04-13 09:07 UTC] thies@php.net
No feedback was provided for this bug, so it is being suspended.
If you are able to provide the information that was requested,
please do so and change the status of the bug back to "Open".

if this itches you too badly you can just take out the exit(-1) call from oci8.c and recompile. but it might kill your oracle MTS

 [2002-12-04 09:38 UTC] ldixon at mail dot communityconnect dot com
I've narrowed down a cause of this error to a lockwait on one or more rows that a query is trying to modify.  This is the simplest way to reproduce:

1) in sqlplus: update table_name set column_2 = column_2_val where column_1 = column_1_val; (do not commit)
2) run the same query from php
3) immediately run this query from another session (a client with a GUI is best for viewing results of this query).  Pay attention to the lockwait column, it will not be null:

select
	count(*) instances,
	se.machine,
	se.osuser,
	sa.executions,
	se.lockwait,
	sa.sql_text
from
	v$sqlarea sa,
	v$session se
where
	sa.address = se.sql_address
and
	sa.hash_value = se.sql_hash_value
and
	sa.executions > 0
and
	se.status = 'ACTIVE'
group by
	se.machine,
	se.osuser,
	sa.executions,
	se.lockwait,
	sa.sql_text
order by instances desc;

4) after a while your php script will come back with OCI8 Recursive call!
5) don't forget to rollback your update in sqlplus!

This is the most simple scenario causing the bug.  The problem also happens on queries I use that operate (DML) on the same data and take a while.  Possible causes of this are users clicking multiple times on links to pages that execute DML queries.  However, sometimes I get this error when there is only one query with a non-null lockwait value.. very strange.

I've tried registering shutdown functions and wrapping the queries that most often produce this error with checks on connection_status() to prevent running the query if user has abandoned the request.  None of these measures have helped the problem.

It's disturbing that the entire apache process has to die because of this.  Any suggestions are welome.
 [2003-05-18 11:52 UTC] sniper@php.net
And way too old php version..

 [2003-11-27 04:31 UTC] jcarlos at wysiwyg dot net
I had the same problem with Solaris+Apache server.
Oracle crashed and the DBA rebooted it, but Apache kept opened Oracle connections. These connections was broken but Apache tried to query Oracle at the same time the new PHP connections did.

The solution was rebooting Apache, and then all worked ok.
PHP version is 4.3
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 02 17:01:35 2024 UTC