php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76092 oci_pconnect returns different errors than oci_connect for unbound binds
Submitted: 2018-03-13 16:48 UTC Modified: 2018-04-10 14:44 UTC
From: robert dot ctr dot berkstresser at faa dot gov Assigned: tianfyan (profile)
Status: Open Package: OCI8 related
PHP Version: 7.2.3 OS: Windows 7
Private report: No CVE-ID: None
 [2018-03-13 16:48 UTC] robert dot ctr dot berkstresser at faa dot gov
Description:
------------
Issue reproduced using PHP 7.1.13 and 7.2.3 x64 Thread Safe builds from https://windows.php.net/download#php-7.2, OCI8 2.1.8 7.2 x64 from PECL and php.ini-development ini. Hosted on Apache 2.4.29 as a module.

Additional extensions:
  php_xdebug-2.6.0-7.2-vc15-x86_64.dll

When code similar to the test script is run within my application the ORA-24343 and Invalid phpbind pointer errors are generated AND php crashes producing this backtrace.

***********************
*  EXCEPTION DETAILS  *
***********************

DetailID = 1
	Count:    2
	Exception #:  0XC0000005
	Stack:        
		OraOCIEI11!lxgcvp+0x5d47
		OraOCIEI11!sigpidu+0x1ea89
		OraOCIEI11!sigpidu+0x11e88
		OraOCIEI11!sigpidu+0x2a2b
		OraOCIEI11!ztub64d+0x28b26
		OraOCIEI11!upicui2+0x9a8
		OraOCIEI11!upirtr+0xad
		OraOCIEI11!kpurcsc+0x96
		OraOCIEI11!kadgetembtype+0xda30
		OraOCIEI11!OCIStmtExecute+0x46
		OCI!OCIStmtExecute+0xb7
		php_oci8!get_module+0x1087a
		php_oci8!get_module+0x994b
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x781e
		php7ts!libiconv_set_relocation_prefix+0x190d8
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x190a5
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x19679
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x19679
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x19679
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x19679
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x19679
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x19679
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!libiconv_set_relocation_prefix+0x19679
		php7ts!zend_throw_exception_ex+0x2502a
		php7ts!execute_ex+0xbf
		php_xdebug_2_6_0_7_2_vc15_x86_64+0x7086
		php7ts!zend_execute+0x1c8
		php7ts!zend_execute_scripts+0xb7
		php7ts!php_execute_script+0x262
		php7apache2_4+0x3daa
		libhttpd!ap_run_handler+0x35
		libhttpd!ap_invoke_handler+0x10f
		libhttpd!ap_internal_redirect_handler+0x29a
		libhttpd!ap_process_request+0x17
		libhttpd!ap_byterange_filter+0x1501
		libhttpd!ap_run_process_connection+0x35
		libhttpd!ap_process_connection+0x45
		libhttpd!ap_run_generate_log_id+0x3d53
		kernel32!BaseThreadInitThunk+0xd
		ntdll!RtlUserThreadStart+0x1d





Test script:
---------------
<?php
$dbc_pass = oci_pconnect('USER', 'PASS', 'DEVBOX');
$bind_value = 'TEST';
$stmt_pass = oci_parse($dbc_pass, "select * from (SELECT 'TEST' as t1 from dual) where t1 = :BND");
oci_bind_by_name($stmt_pass, 'BND', $bind_value, -1, SQLT_CHR);
oci_execute($stmt_pass);
oci_free_statement($stmt_pass);
oci_rollback($dbc_pass);
oci_close($dbc_pass);
unset($stmt_pass);
unset($dbc_pass);

$dbc_fail = oci_pconnect('USER', 'PASS', 'DEVBOX');
$stmt_fail = oci_parse($dbc_fail, "select * from (SELECT 'TEST' as t1 from dual) where t1 = :BND");
oci_execute($stmt_fail);
oci_free_statement($stmt_fail);
oci_rollback($dbc_fail);
oci_close($dbc_fail);
unset($stmt_fail);
unset($dbc_fail);
?>

Expected result:
----------------
Warning: oci_execute(): ORA-01008: not all variables bound in php_test.php on line 15
Call Stack:
    0.0000     398304   1. {main}() php_test.php:0
    0.2340     398856   2. oci_execute() php_test.php:15

Actual result:
--------------
Warning: oci_execute(): Invalid phpbind pointer value in php_test.php on line 15
Call Stack:
    0.0000     398304   1. {main}() php_test.php:0
    0.1248     398568   2. oci_execute() php_test.php:15

Warning: oci_execute(): ORA-24343: user defined callback error in php_test.php on line 15
Call Stack:
    0.0000     398304   1. {main}() php_test.php:0
    0.1248     398568   2. oci_execute() php_test.php:15

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-03-28 01:09 UTC] tianfyan@php.net
The behavior of returning a different error is not a bug.

Please note Ora-01008 is returned from Oracle DB, while "invalid phpbind pointer" error is thrown by OCI8 client.

The different errors are due to the difference between oci_pconnect() and oci_connect();

oci_pconnect() creates a persistent connection of which DB session can survive from oci_close() for a reuse purpose. In the above test, the statement is successfully bound in the 1st connection. And the 2nd oci_pconnect() reuses the session, therefore DB server doesn't return Ora-01008. However, the statement resourse is freed and reallocated in PHP, so OCI8 complains the bind variable is invalid.

In contrast, oci_connect() creates a standard connection which is destoryed by oci_close(). The 2nd oci_connect() begins a brand-new session where the statement is not bound, hence DB returns Ora-01008. 

Are you saying the testcase ends up with a crash? I didn't see a crash in my env. Please confirm.
 [2018-03-28 01:27 UTC] sixd@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: tianfyan
 [2018-04-03 17:11 UTC] robert dot ctr dot berkstresser at faa dot gov
-Status: Feedback +Status: Assigned
 [2018-04-03 17:11 UTC] robert dot ctr dot berkstresser at faa dot gov
Original Test case does not crash. It only exhibits the error behavior.

I was able to put together one that does crash. These Results are on my machine using originally listed specs, minus xdebug.
I was also able to reproduce the problem on a windows 10 vm with the other specs remaining the same.

Put this in a default.php file in your webroot.
<?php
$dbc1 = oci_pconnect('USER', 'PASS', 'DEVBOX');
$bind_value = 'TEST';

$stmt_pass = oci_parse($dbc1, "select * from (SELECT 'TEST' as t1 from dual) where t1 = :BND");
oci_bind_by_name($stmt_pass, 'BND', $bind_value, -1, SQLT_CHR);
oci_execute($stmt_pass);
oci_free_statement($stmt_pass);
echo 'TEST RUN ' . time();
?>

1. Navigate to your webroot it should return a screen with TEST RUN and the epoch on it.
2. Then comment out the oci_bind_by_name and refresh the browser.
   (If it does not crash try again from the beginning. Sometimes it requires two or three cycles to crash.)
3. The request hangs for about a second.
4. httpd.exe memory use goes up from about 30mb to 250mb.
5. httpd.exe crashes
6. httpd.exe restarts
7. Then PHP shows me the error: "Warning: oci_execute(): ORA-01008: not all variables bound".
   (I assume it shows this instead of the phpbind error because it loses the statement cache on restart or something...)

Apache writes this to its error log:
[Wed Mar 28 09:31:58.644901 2018] [mpm_winnt:notice] [pid 9752:tid 388] AH00428: Parent: child process 14032 exited with status 4294967295 -- Restarting.
[Wed Mar 28 09:31:59.930030 2018] [mpm_winnt:notice] [pid 9752:tid 388] AH00455: Apache/2.4.29 (Win64) PHP/7.2.3 configured -- resuming normal operations
[Wed Mar 28 09:31:59.930030 2018] [mpm_winnt:notice] [pid 9752:tid 388] AH00456: Apache Lounge VC15 Server built: Nov  3 2017 11:12:00

Sometimes the exited with status is 3221225477.

This is another exception stack I get.
***********************
*  EXCEPTION DETAILS  *
***********************

DetailID = 1
	Count:    1
	Exception #:  0XC0000005
	Stack:        
		php7ts!libiconv_set_relocation_prefix+0x4ad
		php_oci8!get_module+0x1303e
		OraOCIEI11!sigpidu+0x11663
		OraOCIEI11!sigpidu+0x124e6
		OraOCIEI11!sigpidu+0x2a2b
		OraOCIEI11!ztub64d+0x28b26
		OraOCIEI11!upicui2+0x9a8
		OraOCIEI11!upirtr+0xad
		OraOCIEI11!kpurcsc+0x96
		OraOCIEI11!kadgetembtype+0xda30
		OraOCIEI11!OCIStmtExecute+0x46
		OCI!OCIStmtExecute+0xb7
		php_oci8!get_module+0x1087a
		php_oci8!get_module+0x994b
		php7ts!php_output_handler_create_internal+0x17b
		php7ts!execute_ex+0xbf
		php7ts!zend_execute+0x1c8
		php7ts!zend_execute_scripts+0xb7
		php7ts!php_execute_script+0x262
		php7apache2_4+0x3daa
		libhttpd!ap_run_handler+0x35
		libhttpd!ap_invoke_handler+0x10f
		libhttpd!ap_internal_redirect_handler+0x29a
		libhttpd!ap_process_request+0x17
		libhttpd!ap_byterange_filter+0x1501
		libhttpd!ap_run_process_connection+0x35
		libhttpd!ap_process_connection+0x45
		libhttpd!ap_run_generate_log_id+0x3d53
		kernel32!BaseThreadInitThunk+0xd
		ntdll!RtlUserThreadStart+0x1d

oci_connect does not crash and always shows the ORA-01008 error. I think this is what lead to my original confusion, when oci_pconnect would sometimes show the callback error and other times show the ORA-01008 error. 

Additionally, this is confusing because if I bind an integer as a SQLT_INT in the example above I receive no error at all.
 [2018-04-10 14:44 UTC] robert dot ctr dot berkstresser at faa dot gov
-Status: Assigned +Status: Open
 [2018-04-10 14:44 UTC] robert dot ctr dot berkstresser at faa dot gov
Set to Open
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Oct 14 04:01:27 2024 UTC