#49615 [Bgs]: Problems with oci_pconnect()
ID: 49615 User updated by: bruno at uniconsult dot com dot br Reported By: bruno at uniconsult dot com dot br Status: Bogus Bug Type: OCI8 related Operating System: linux PHP Version: 5.2.11 New Comment: I downloaded and installed oci8 1.3.5 from PECL web site and re-compiled PHP (updated to version 5.2.11) with it. Unfortunately, oci_pconnect() calls keep 'dazing' apache child process. Looking at the stack again, I noticed that the execution is hanging on the OCIPing() call - and again on a __read_nocancel() call. Here is the new stack: #0 0x00335370b25f in __read_nocancel () from /lib64/tls/libpthread.so.0 #1 0x002a97cd183e in snttread () #2 0x002a97cd15f9 in nttfprd () #3 0x002a97cc986e in nsbasic_brc () #4 0x002a97ccc6d1 in nsbrecv () #5 0x002a97cbb4fd in nioqrc () #6 0x002a97cf6642 in ttcdrv () #7 0x002a97cc210d in nioqwa () #8 0x002a97ca876b in upirtrc () #9 0x002a963e7349 in upirtr () #10 0x002a9643d443 in kpurcs () #11 0x002a96405898 in kpuping () #12 0x002a963eb2c1 in OCIPing () #13 0x002a95900cbc in php_oci_connection_ping () #14 0x002a95902e98 in php_oci_create_session () #15 0x002a959055ba in php_oci_do_connect_ex () #16 0x002a95905c8e in php_oci_do_connect () #17 0x002a95916316 in zif_oci_pconnect () #18 0x002a95aa99ce in zend_do_fcall_common_helper_SPEC () #19 0x002a95aa8fe1 in execute () from /opt/apache2/modules/libphp5.so #20 0x002a95aa92e3 in zend_do_fcall_common_helper_SPEC () #21 0x002a95aa8fe1 in execute () from /opt/apache2/modules/libphp5.so #22 0x002a95aa92e3 in zend_do_fcall_common_helper_SPEC () #23 0x002a95aa8fe1 in execute () from /opt/apache2/modules/libphp5.so #24 0x002a95af91fd in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER () #25 0x002a95aa8fe1 in execute () from /opt/apache2/modules/libphp5.so #26 0x002a95af91fd in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER () #27 0x002a95aa8fe1 in execute () from /opt/apache2/modules/libphp5.so #28 0x002a95ac38a3 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER () #29 0x002a95aa8fe1 in execute () from /opt/apache2/modules/libphp5.so #30 0x002a95a8a004 in zend_execute_scripts () #31 0x002a95a477ad in php_execute_script () #32 0x002a95b194b6 in php_handler () from /opt/apache2/modules/libphp5.so #33 0x00435d13 in ap_run_handler () #34 0x004361b1 in ap_invoke_handler () #35 0x0044dc20 in ap_process_request () #36 0x0044b36d in ap_process_http_connection () #37 0x0043c7d3 in ap_run_process_connection () #38 0x004681b0 in child_main () #39 0x00468404 in make_child () #40 0x0046849e in startup_children () #41 0x00468cad in ap_mpm_run () #42 0x004236f5 in main () Thanks Previous Comments: [2009-09-22 19:42:37] bruno at uniconsult dot com dot br Thanks for the reply, I will update the versions and make some tests [2009-09-21 22:23:04] s...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. --- Please try OCI8 1.3. This is included in PHP 5.3, and is available in PECL for older versions of PHP: http://pecl.php.net/oci8. The connection logic was substantially changed. It also detects and recovers from dead connections better. [2009-09-21 19:43:53] bruno at uniconsult dot com dot br Description: I got some problems with an application using persistent connections. When calling the oci_pconnect() function, if for any reason i got no response from the database, the PHP script keeps waiting and there is not a way to timeout it. In a unix shell script this can be solved using alarms and signals. Is there some oci8 approach to handle connections timeouts? Important, my problem is not in closing the connection in database, is to get some response when oci_pconnect() get no response and a way to handle it. I made a shell script to trace the execution stack and I noticed that the last call 'hangs': #0 0x00335370b222 in __read_nocancel () from /lib64/tls/libpthread.so.0 #1 0x002a97cc283e in snttread () #2 0x002a97cc25f9 in nttfprd () #3 0x002a97cba86e in nsbasic_brc () #4 0x002a97cbd6d1 in nsbrecv () #5 0x002a97cac4fd in nioqrc () #6 0x002a97ce7642 in ttcdrv () #
#49615 [Bgs]: Problems with oci_pconnect()
ID: 49615 User updated by: bruno at uniconsult dot com dot br Reported By: bruno at uniconsult dot com dot br Status: Bogus Bug Type: OCI8 related Operating System: linux PHP Version: 5.2.11 New Comment: Thanks for the reply, I will update the versions and make some tests Previous Comments: [2009-09-21 22:23:04] s...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. --- Please try OCI8 1.3. This is included in PHP 5.3, and is available in PECL for older versions of PHP: http://pecl.php.net/oci8. The connection logic was substantially changed. It also detects and recovers from dead connections better. [2009-09-21 19:43:53] bruno at uniconsult dot com dot br Description: I got some problems with an application using persistent connections. When calling the oci_pconnect() function, if for any reason i got no response from the database, the PHP script keeps waiting and there is not a way to timeout it. In a unix shell script this can be solved using alarms and signals. Is there some oci8 approach to handle connections timeouts? Important, my problem is not in closing the connection in database, is to get some response when oci_pconnect() get no response and a way to handle it. I made a shell script to trace the execution stack and I noticed that the last call 'hangs': #0 0x00335370b222 in __read_nocancel () from /lib64/tls/libpthread.so.0 #1 0x002a97cc283e in snttread () #2 0x002a97cc25f9 in nttfprd () #3 0x002a97cba86e in nsbasic_brc () #4 0x002a97cbd6d1 in nsbrecv () #5 0x002a97cac4fd in nioqrc () #6 0x002a97ce7642 in ttcdrv () #7 0x002a97cb310d in nioqwa () #8 0x002a97c9976b in upirtrc () #9 0x002a963d8349 in upirtr () #10 0x002a9645e369 in upiver () #11 0x002a96ddaa80 in kpuvers () #12 0x002a96cce2cb in OCIServerVersion () #13 0x002a958ff12a in php_oci_do_connect_ex () #14 0x002a958ff580 in php_oci_do_connect () #15 0x002a9590a2e6 in zif_oci_pconnect () #16 ... -- Edit this bug report at http://bugs.php.net/?id=49615&edit=1
#49615 [NEW]: Problems with oci_pconnect()
From: bruno at uniconsult dot com dot br Operating system: linux PHP version: 5.2.11 PHP Bug Type: OCI8 related Bug description: Problems with oci_pconnect() Description: I got some problems with an application using persistent connections. When calling the oci_pconnect() function, if for any reason i got no response from the database, the PHP script keeps waiting and there is not a way to timeout it. In a unix shell script this can be solved using alarms and signals. Is there some oci8 approach to handle connections timeouts? Important, my problem is not in closing the connection in database, is to get some response when oci_pconnect() get no response and a way to handle it. I made a shell script to trace the execution stack and I noticed that the last call 'hangs': #0 0x00335370b222 in __read_nocancel () from /lib64/tls/libpthread.so.0 #1 0x002a97cc283e in snttread () #2 0x002a97cc25f9 in nttfprd () #3 0x002a97cba86e in nsbasic_brc () #4 0x002a97cbd6d1 in nsbrecv () #5 0x002a97cac4fd in nioqrc () #6 0x002a97ce7642 in ttcdrv () #7 0x002a97cb310d in nioqwa () #8 0x002a97c9976b in upirtrc () #9 0x002a963d8349 in upirtr () #10 0x002a9645e369 in upiver () #11 0x002a96ddaa80 in kpuvers () #12 0x002a96cce2cb in OCIServerVersion () #13 0x002a958ff12a in php_oci_do_connect_ex () #14 0x002a958ff580 in php_oci_do_connect () #15 0x002a9590a2e6 in zif_oci_pconnect () #16 ... -- Edit bug report at http://bugs.php.net/?id=49615&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49615&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49615&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49615&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49615&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49615&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49615&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49615&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49615&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49615&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49615&r=support Expected behavior: http://bugs.php.net/fix.php?id=49615&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49615&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49615&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49615&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49615&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49615&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49615&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49615&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49615&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49615&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49615&r=mysqlcfg
