Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


+------------------------------------------------------------
| I couldn't reproduce it.
| Thanks for reporting the bug, but please include a complete
| testcase so I don't have to guess what the code might be.
| Also, what does "stop work" mean?
+------------------------------------------------------------

<?php

/**
* ORACLE Storage Procedure
*
* create or replace procedure sp_vadik_1 ( out_1 out sys_refcursor ) is begin
* open out_1 for select 11 from dual union all select 12 from dual union all select 13 from dual;
* end sp_vadik_1; 
*/

$params_db = array( 'host' => "localhost", 'username' => "username", 'password' => "password", 'dbname' => "db" );

putenv( 'ORACLE_SID=' . $params_db['dbname'] );
$conn_string = '(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=' . $params_db['host'] . ')(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=' . $params_db['dbname'] . ')))';

$connection = @oci_connect( $params_db['username'], $params_db['password'], $conn_string );



//------------ START EXECUTE 1 ---------------//
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );

oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );

while( $row = oci_fetch_array( $cursor, OCI_ASSOC + OCI_RETURN_LOBS ) )
{
    $data[] = $row;
}

oci_free_statement( $stmt );
oci_free_statement( $cursor );
//------------ STOP EXECUTE 1 ---------------//



//------------ START EXECUTE 2 ---------------//
$sql = "BEGIN sp_vadik_1( :cursor1 ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor1", $cursor, -1, OCI_B_CURSOR );

oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );

while( $row = oci_fetch_array( $cursor, OCI_ASSOC + OCI_RETURN_LOBS ) )
{
    $data[] = $row;
}

oci_free_statement( $stmt );
oci_free_statement( $cursor );
var_dump($cur2);
//------------ STOP EXECUTE 2 ---------------//

oci_close( $connection );


?>

Sorry, need change lines in EXECUTE 2 (for reproduction errors).
SQL and bind param must be the same for both executions:

$sql = "BEGIN sp_vadik_1( :cursor ); END;";
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );

"stop work" - this crash PHP.
If run this script in command line, i see error "segmentation false"

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

This script working normally if not reopen cursor.

Bad result:
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );

$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );

Good result:
$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
$cursor = oci_new_cursor( $connection );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );

$sql = "BEGIN sp_vadik_1( :cursor ); END;";
$stmt = oci_parse( $connection, $sql );
oci_bind_by_name( $stmt, ":cursor", $cursor, -1, OCI_B_CURSOR );
oci_execute( $stmt, OCI_DEFAULT );
oci_execute( $cursor );
oci_free_statement( $stmt );
oci_free_statement( $cursor );

I reproduced the crash.  The problem appears to be the same as reported in http://bugs.php.net/bug.php?id=43340.  If you change the PL/SQL package definition so out_1 is an "IN OUT" parameter, there is no crash.

This fix only works for out parameters, not for return values from functions. I can't change thosea.
I also filed the bug (Bug #43449), haven't found the other two.

The original testcase (with the parameter only as OUT) does not crash with OCI8 1.3.0 Beta from PECL.

This was a latent bug exposed when statement caching was fixed.
The temporary workaround is to set oci8.statement_cache_size=0

The real solution (thanks to Sree) is to add a missing case for
cursors to the out-bind callback:

diff -u oci8_statement.c.orig oci8_statement.c
--- oci8_statement.c.orig	2008-01-30 10:37:32.000000000 -0800
+++ oci8_statement.c	2008-01-30 10:21:31.000000000 -0800
@@ -1174,6 +1174,14 @@
 	}
 
 	if (Z_TYPE_P(val) == IS_RESOURCE) {
+		/* Processing for ref-cursor out binds */
+		if (phpbind->statement != NULL) {
+			*bufpp = phpbind->statement;
+			*alenpp = &phpbind->dummy_len;
+			*piecep = OCI_ONE_PIECE;
+			*rcodepp = &phpbind->retcode;
+			*indpp = &phpbind->indicator;
+		}
 		retval = OCI_CONTINUE;
 	} else if (Z_TYPE_P(val) == IS_OBJECT) {
 		if (!phpbind->descriptor) {

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.