php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #30697 SIGSEGV, Segmentation fault
Submitted: 2004-11-05 23:24 UTC Modified: 2005-01-15 01:00 UTC
Votes:14
Avg. Score:4.6 ± 0.6
Reproduced:14 of 14 (100.0%)
Same Version:9 (64.3%)
Same OS:7 (50.0%)
From: withpaul at yahoo dot com Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 5.0.2 OS: sparc-sun-solaris2.8
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
26 + 26 = ?
Subscribe to this entry?

 
 [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


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-11-05 23:27 UTC] withpaul at yahoo dot com
PHP is running under Apache2 in MOD mode - not CGI mode.
 [2004-11-17 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2004-11-17 03:13 UTC] withpaul at yahoo dot com
Presently we can't make any changes to the system in question. Until we can, please put this on hold. Thankyou.
 [2004-11-17 10:04 UTC] derick@php.net
Leave status at "feedback" until we get info.
 [2004-11-19 12:28 UTC] marek dot raida at oskar dot cz
I have the same problems. PHP 5.0.2, Solaris 9, and Apache 2 -> probably problem lies in new Apache and hanle with OCI drivers. The same errors as mentioned other people, randomly disappearing, but most of the time still alerting:
Warning: Unknown: _oci_close_session OCIHandleAlloc OCI_HTYPE_SVCCTX: OCI_INVALID_HANDLE in Unknown on line 0
Warning: Unknown: _oci_close_session: OCIAttrSet OCI_ATTR_SERVER: OCI_INVALID_HANDLE in Unknown on line 0
Warning: Unknown: _oci_close_session: OCIAttrSet OCI_ATTR_SESSION: OCI_INVALID_HANDLE in Unknown on line 0
Warning: Unknown: _oci_close_session: OCISessionEnd: OCI_INVALID_HANDLE in Unknown on line 0

I critically need to solve this, because of we are in half of great project and we are not able to move back to PHP4 now, so perhaps switch from Apache2 to Apache 1.3.x will help. Or not?

Thx,
Marek R.
 [2004-12-07 19:46 UTC] shawn dot coomey at cubist dot com
Same issue here. Freshly compiled PHP 5.0.2, Apache 1.3.29 (note that the other folks with the problem are using Apache 2) on Solaris 8 using the OCI functions to connect to an Oracle 9i database. 

No core dump in my case. Just displaying these errors about 90% of the time.
 [2004-12-13 09:15 UTC] marek dot raida at oskar dot cz
Our problems are now not so often, after we put our manual connection close to all DB connections before script end, as we trust PHP's auto close no more. Try the same and perhaps it will help you too.
 [2004-12-14 16:56 UTC] tony2001@php.net
marek dot raida at oskar dot cz:
And how do you "close" them? 
ocilogoff() is an empty function, which does nothing for a long time and personally I can't find any way to "close connection manually".

shawn dot coomey at cubist dot com:
I asked initial reporter to try CVS snapshot and not 5.0.2. Please, give it a try.
 [2004-12-21 07:41 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2005-01-07 14:24 UTC] marek dot raida at guide dot cz
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.
 [2005-01-07 15:01 UTC] tony2001@php.net
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 possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.


 [2005-01-07 16:21 UTC] marek dot raida at oskar dot cz
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);

?>
 [2005-01-15 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2005-01-27 17:01 UTC] lussnig at smcc dot de
Hello,
i had the same Problem with php-5.0.0
With 5.0.3 it is fixed.
 [2005-01-27 17:02 UTC] lussnig at smcc dot de
The OS is not dependent on sparc the problem was under Linux too. also Version should be 5.0.0 up to 5.0.2
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 22:01:26 2024 UTC