ID: 42496
Comment by: michael dot virnstein at brodos dot de
Reported By: iddekingej at lycos dot com
Status: Open
Bug Type: OCI8 related
Operating System: win 2000
PHP Version: 5.2.4
New Comment:
I tried to remove "zend_list_addref(outcol->statement->id);" from
SQLT_RSET in php_oci_define_callback function() as well, but that
doesn't work really well. It seemed to work at first, but it creates
problems when returning the cursor from a function, because it leads to
"ORA-01001: invalid cursor" when i try to fetch from the returned
cursor.
Testcase:
<?php
$conn = ocilogon('user', 'pass', 'db');
function fetch($conn, $id)
{
$result = null;
$stmt = ociparse($conn, 'select cursor(select * from dual) c from
dual');
ociexecute($stmt, OCI_DEFAULT);
ocifetchinto($stmt, $result, OCI_ASSOC);
ociexecute($result['C'], OCI_DEFAULT);
return $result['C'];
}
for ($id = 1; $id <= 300; $id++) {
$cur = fetch($conn, $id);
ocifetchinto($cur, $row, OCI_ASSOC);
ocifreestatement($cur);
}
?>
When i run the code above without removing
"zend_list_addref(outcol->statement->id);" from SQLT_RSET i have the
problem, that i get an "ORA-01000: maximum open cursors exceeded",
because the statement within the function doesn't get closed.
I don't know if that can be implemented easily, but the best thing
would be, that a cursor gets closed if it is already out of scope and
therefore not accessible from the php-code anymore and all nested
cursors got closed already.
Previous Comments:
------------------------------------------------------------------------
[2007-11-30 16:30:55] michael at six dot de
Same problem here: php 5.2.5 with oracle 11g client (linux 64bit)
against oracle 10.2.0.3 server (solaris 10 sparc 64bit).
Patch works ok, no ORA-01000 errors anymore.
------------------------------------------------------------------------
[2007-11-30 10:05:28] michael dot virnstein at brodos dot de
Thanks, this fix works for lobs, but i investigated a bit further and
realized, that the same problem occures when returning cursors.
To totally remove the problem you would have to remove
"zend_list_addref(outcol->statement->id);" from SQLT_RSET in
php_oci_define_callback() also.
I don't know if this is the right solution at all, i'm not that much
into the php-engine, oci8-library and C in general. Wouldn't it be
better to close all related cursors when closing the "main"-cursor
instead of not registering them?
------------------------------------------------------------------------
[2007-11-29 18:01:29] [EMAIL PROTECTED]
This was reproduced with 5.2.3 on Linux.
Please try this patch AND LET US KNOW THE RESULT - thanks!
In php_oci_define_callback function [oci8_statement.c],
zend_list_addref is called for every lob column of each row. When we
commented out this increment, the statements were destroyed and no
cursor leaks were seen.
case SQLT_RDD:
case SQLT_BLOB:
case SQLT_CLOB:
case SQLT_BFILE: {
...
descr = php_oci_lob_create(outcol->statement->connection, dtype
TSRMLS_CC);
if (!descr) {
return OCI_ERROR;
}
/*zend_list_addref(outcol->statement->id); Commented out
*/
------------------------------------------------------------------------
[2007-11-29 16:38:45] michael dot virnstein at brodos dot de
I recognized, that when calling oci_free_statement() for every lob
column that is returned by the select, the cursor gets closed
correctly.
So if i have three lob columns in the query, i have to call
oci_free_statment() three times on the statement handle to have it
closed correctly.
------------------------------------------------------------------------
[2007-11-22 10:01:34] ghosh at q-one dot com
I'm using OCI8 1.2.4 with Oracle 11g. A previous version doesnt seem to
work, so I cannot test with 1.2.3. It also says so in the changelog for
1.2.4: Add Oracle 11g support. Now, whenever I select (c)lobs (even with
only 1 lob column),, the table v$temporary_lobs keeps filling up and UGA
memory is consumed for each row that's being read until the server
aborts with an out-of-memory error. This does not happen when I run my
statements directly via SQLplus, so it seems to be an OCI8/PHP bug. So,
is this related to this bug or should I file a new one?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42496
--
Edit this bug report at http://bugs.php.net/?id=42496&edit=1
