|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2004-11-05 23:24 UTC] withpaul at yahoo dot com
Description: ------------ Apache must be restarted after PHP error. Receiving intermittent error within 1-20 minutes after starting / restarting Apache2 server when any given random OCI function call against an Oracle9 database server occurs. NOTE: firewall exists between the Apache host server and Oracle server (suspect and cannot test bypassing firewall due to extended policy process at organization): PHP Warning: Unknown: _oci_close_session OCIHandleAlloc OCI_HTYPE_SVCCTX: OCI_INVALID_HANDLE in Unknown on line 0, referer: [http://mysitex.domain.com/something.php] Unknown(0) : Warning - Unknown: _oci_close_session OCIHandleAlloc OCI_HTYPE_SVCCTX: OCI_INVALID_HANDLE TEMPORARY DIAGNOSIS AND STRATEGY UNTIL FIREWALL CAN BE BYPASSED FOR FURTHER TESTING: We were using: http://www.php.net/manual/en/function.session-set-save-handler.php We are now using: Turning off database management of session related info and enabling following in PHP.INI: session.save_handler = files session.save_path = /tmp (a writeable directory by Apache5) (then confirming that session related temporary files are being opened in session.save_path) Ploblem no longer occurring at present. (36+ hours) Believe it is a firewall or OCI connectivity issue with the Oracle server. Question: With the included TraceLog (minus the GDB error), can we avoid from a PHP source perspective, an Apache2 segfault? It may be awhile before we can ascertain what causes this problem such as the suspected firewall between servers or some process on the web server that may be interfering. Reproduce code: --------------- Intermittent issue - not consistently reproducable. Actual result: -------------- Program received signal SIGSEGV, Segmentation fault. 0xfdcd27e4 in _oci_close_session (session=0x2e8c68) at /usr/local/src/php-5.0.2/ext/oci8/oci8.c:2941 2941 CALL_OCI_RETURN(OCI(error), (gdb) bt #0 0xfdcd27e4 in _oci_close_session (session=0x2e8c68) at /usr/local/src/php-5.0.2/ext/oci8/oci8.c:2941 #1 0xfdccc368 in _oci_session_list_dtor (rsrc=0x2d1ab0) at /usr/local/src/php-5.0.2/ext/oci8/oci8.c:1124 #2 0xfdeed8b8 in list_entry_destructor (ptr=0x2d1ab0) at /usr/local/src/php-5.0.2/Zend/zend_list.c:178 #3 0xfdeea414 in zend_hash_apply_deleter (ht=0xfe0f0b10, p=0x22aa18) at /usr/local/src/php-5.0.2/Zend/zend_hash.c:574 #4 0xfdeea7c4 in zend_hash_graceful_reverse_destroy (ht=0xfe0f0b10) at /usr/local/src/php-5.0.2/Zend/zend_hash.c:640 #5 0xfdeedb34 in zend_destroy_rsrc_list (ht=0xfe0f0b10) at /usr/local/src/php-5.0.2/Zend/zend_list.c:234 #6 0xfdec711c in shutdown_executor () at /usr/local/src/php-5.0.2/Zend/zend_execute_API.c:285 #7 0xfdedd0b0 in zend_deactivate () at /usr/local/src/php-5.0.2/Zend/zend.c:818 #8 0xfde66bb8 in php_request_shutdown (dummy=0x0) at /usr/local/src/php-5.0.2/main/main.c:1212 #9 0xfdf29d68 in php_apache_request_dtor (r=0x1edbf0) at /usr/local/src/php-5.0.2/sapi/apache2handler/sapi_apache2.c:435 #10 0xfdf2a58c in php_handler (r=0x1edbf0) at /usr/local/src/php-5.0.2/sapi/apache2handler/sapi_apache2.c:553 #11 0x00046388 in ap_run_handler (r=0x1edbf0) at config.c:151 ---Type <return> to continue, or q <return> to quit--- #12 0x0004692c in ap_invoke_handler (r=0x1edbf0) at config.c:363 #13 0x00033c74 in ap_process_request (r=0x1edbf0) at http_request.c:246 #14 0x0002f15c in ap_process_http_connection (c=0x1e2bd8) at http_core.c:250 #15 0x000519ec in ap_run_process_connection (c=0x1e2bd8) at connection.c:42 #16 0x00044c7c in child_main (child_num_arg=1969000) at prefork.c:609 #17 0x00044e5c in make_child (s=0x99950, slot=0) at prefork.c:649 #18 0x00044ee0 in startup_children (number_to_start=4) at prefork.c:721 #19 0x000456a0 in ap_mpm_run (_pconfstabsread.c:624: internal-error: sect_index_data not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n stabsread.c:624: internal-error: sect_index_data not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n ) at prefork.c:940 #20 0x0004b36c in main (argc=2, argv=0xffbefc84) at main.c:617 Here's the "frame" data for each line above... (gdb) frame 0 #0 0xfdcd27e4 in _oci_close_session (session=0x2e8cb0) at /usr/local/src/php-5.0.2/ext/oci8/oci8.c:2941 2941 CALL_OCI_RETURN(OCI(error), (gdb) frame 1 #1 0xfdccc368 in _oci_session_list_dtor (rsrc=0x2d1b30) at /usr/local/src/php-5.0.2/ext/oci8/oci8.c:1124 1124 _oci_close_session(session); (gdb) frame 2 #2 0xfdeed8b8 in list_entry_destructor (ptr=0x2d1b30) at /usr/local/src/php-5.0.2/Zend/zend_list.c:178 178 ld->list_dtor_ex(le TSRMLS_CC); (gdb) frame 3 #3 0xfdeea414 in zend_hash_apply_deleter (ht=0xfe0f0b10, p=0x215898) at /usr/local/src/php-5.0.2/Zend/zend_hash.c:574 574 ht->pDestructor(p->pData); (gdb) frame 4 #4 0xfdeea7c4 in zend_hash_graceful_reverse_destroy (ht=0xfe0f0b10) at /usr/local/src/php-5.0.2/Zend/zend_hash.c:640 640 zend_hash_apply_deleter(ht, p); (gdb) frame 5 #5 0xfdeedb34 in zend_destroy_rsrc_list (ht=0xfe0f0b10) at /usr/local/src/php-5.0.2/Zend/zend_list.c:234 234 zend_hash_graceful_reverse_destroy(ht); (gdb) frame 6 #6 0xfdec711c in shutdown_executor () at /usr/local/src/php-5.0.2/Zend/zend_execute_API.c:285 285 zend_destroy_rsrc_list(&EG(regular_list) TSRMLS_CC); (gdb) frame 7 #7 0xfdedd0b0 in zend_deactivate () at /usr/local/src/php-5.0.2/Zend/zend.c:818 818 shutdown_executor(TSRMLS_C); (gdb) frame 8 #8 0xfde66bb8 in php_request_shutdown (dummy=0x0) at /usr/local/src/php-5.0.2/main/main.c:1212 1212 zend_deactivate(TSRMLS_C); (gdb) frame 9 #9 0xfdf29d68 in php_apache_request_dtor (r=0x1f1c00) at /usr/local/src/php-5.0.2/sapi/apache2handler/sapi_apache2.c:435 435 php_request_shutdown(NULL); (gdb) frame 10 #10 0xfdf2a58c in php_handler (r=0x1f1c00) at /usr/local/src/php-5.0.2/sapi/apache2handler/sapi_apache2.c:553 553 php_apache_request_dtor(r TSRMLS_CC); (gdb) frame 11 #11 0x00046388 in ap_run_handler (r=0x1f1c00) at config.c:151 151 config.c: No such file or directory. in config.c (gdb) frame 12 #12 0x0004692c in ap_invoke_handler (r=0x1f1c00) at config.c:363 363 in config.c (gdb) frame 13 #13 0x00033c74 in ap_process_request (r=0x1f1c00) at http_request.c:246 246 http_request.c: No such file or directory. in http_request.c (gdb) frame 14 #14 0x0002f15c in ap_process_http_connection (c=0x1e2bd8) at http_core.c:250 250 http_core.c: No such file or directory. in http_core.c (gdb) frame 15 #15 0x000519ec in ap_run_process_connection (c=0x1e2bd8) at connection.c:42 42 connection.c: No such file or directory. in connection.c (gdb) frame 16 #16 0x00044c7c in child_main (child_num_arg=1969000) at prefork.c:609 609 prefork.c: No such file or directory. in prefork.c (gdb) frame 17 #17 0x00044e5c in make_child (s=0x99950, slot=0) at prefork.c:649 649 in prefork.c (gdb) frame 18 #18 0x00044ee0 in startup_children (number_to_start=4) at prefork.c:721 721 in prefork.c (gdb) frame 19 #19 0x000456a0 in ap_mpm_run (_pconfstabsread.c:624: internal-error: sect_index_data not initialized Here's the server error log entry for this... [client 127.0.0.1] PHP Warning: Unknown: _oci_close_session OCIHandleAlloc OCI_HTYPE_SVCCTX: OCI_INVALID_HANDLE in Unknown on line 0, referer: http://qa1profiles.fcprofiles.com/xq25/admin/login.php Unknown(0) : Warning - Unknown: _oci_close_session OCIHandleAlloc OCI_HTYPE_SVCCTX: OCI_INVALID_HANDLE PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Thu Dec 26 14:01:30 2024 UTC |
Hi there, we made some investigation and found 100% way of reproducing error: PHP Warning: Unknown: _oci_close_session OCIHandleAlloc OCI_HTYPE_SVCCTX: OCI_INVALID_HANDLE in Unknown on line 0. It has to do with creating OCIParse in function/object's method and returning it as member of array. Mst be not alone in array. Steps. 1. Connect to Oracle 2. Prepare statement inside function and return it in array 3. End script immediatelly (without execution). Example: function xxx($sql,$conn){ $stmt = OCIParse($conn,$sql); return array($sql,$stmt); } $conn = $this->wscDb->connect(); // for example $stmt = xxx('select 123 from dual', $conn); var_dump($conn,$stmt); die('watch crash'); This principle is used in John Lim's ADO DB framework. My env. is PHP 5.0.x, OCI client 9.x, Solaris.. (as described in previous report). I found way to avoid this by returning not simple array, but the same array as property of object and everything works well. Returning standar PHP array with more than one member leads to the error. Hope this will help in finding where the problme lies... cheers, Marek R.There is the smallest example was able to prepare. Problem is with calling abc() before connection to Database. OS: SunOS s1self31 5.9 Generic_117171-08 sun4u PHP: PHP Version 5.0.2 OCI Client: --with-oci8=/app/oracle/product/9.2.0.1_client ORACLE: 9.2.0.4.0 (using UTF-8) Are you able to reproduce it? It works 100%l for me.... M.R. -------- <?php function abc(){} function crash($sql,$conn){ $stmt = OCIParse($conn,$sql); return array($stmt,1); } abc(); $conn = ociplogon('wsc_own','wsc_own123','PUB_DEV'); $stmt = crash('select 123 from dual', $conn); var_dump($conn,$stmt); ?>