#43492 [NEW]: cursor not closed when selecting more than one cursor

From: michael dot virnstein at brodos dot de Operating system: Linux PHP version: 5.2.5 PHP Bug Type: OCI8 related Bug description: cursor not closed when selecting more than one cursor Description: ------------ As requested in Bug #42496 (http://bugs.php.net/bug.php?id=42496), here's a separate bug report for the cursor issue: If you use a query with more than one cursor as result column, the statement won't get closed correctly. You have to call oci_free_statement() for as many times as there are result-cursors to get the statement closed correctly. I tried the fix for LOBs as reported in Bug #42496 for SQLT_RSET, but that didn't work really well. There are two problems: 1. If you use the reproduce code below with the fix (removing "zend_list_addref(outcol->statement->id);" from SQLT_RSET in php_oci_define_callback function() [oci8_statement.c]), you'll get an "ORA-01001: invalid cursor" when you try to fetch from the returned cursor. It seems that the statement ($stmt) is closed when leaving the function. 2. If you use the reproduce code below without the fix above, you'll get an "ORA-01000: maximum open cursors exceeded" when you hit you're "open_cursors" db-setting. The statement ($stmt) never gets closed and leaves a dangling cursor. I don't know if that can be implemented easily, but the best thing would be, that a statement 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. Reproduce code: --------------- <?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); } ?> Expected result: ---------------- Neither an "ORA-01001: invalid cursor" nor an "ORA-01000: maximum open cursors exceeded" Actual result: -------------- Depends on the fix. Either "ORA-01001: invalid cursor" or "ORA-01000: maximum open cursors exceeded" -- Edit bug report at http://bugs.php.net/?id=43492&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43492&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43492&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43492&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43492&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43492&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43492&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43492&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=43492&r=needscript Try newer version: http://bugs.php.net/fix.php?id=43492&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43492&r=support Expected behavior: http://bugs.php.net/fix.php?id=43492&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43492&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43492&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43492&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43492&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43492&r=dst IIS Stability: http://bugs.php.net/fix.php?id=43492&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43492&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43492&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43492&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=43492&r=mysqlcfg