php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24531 [PATCH] Closing an Oracle Session produces SIGSEV
Submitted: 2003-07-08 02:42 UTC Modified: 2003-12-12 07:58 UTC
Votes:4
Avg. Score:4.2 ± 0.4
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:1 (33.3%)
From: Manfred dot Metz at rsd dot rohde-schwarz dot com Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4CVS, 5CVS OS: Solaris 8 (SPARC)
Private report: No CVE-ID: None
 [2003-07-08 02:42 UTC] Manfred dot Metz at rsd dot rohde-schwarz dot com
Description:
------------
When running a PHP Skript with Oracle calls then very often the apache process dies and produces a SIGSEV error.

My configuration is:

./configure
--with-apache=../apache_1.3.27
--with-xml
--enable-wddx
--with-ldap=/usr/local
--with-openssl=/usr/local/ssl
--with-curl=/usr/local
--with-zlib
--with-oci8=/opt/oracle/ora920
--without-mysql
--with-config-file-path=/etc/apache
--enable-debug
--prefix=/usr/local

The first occurrence of the error has the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xfebf0b1c in sltstcu () from /opt/ora920/ora920/lib/libclntsh.so.9.0
(gdb) bt
#0  0xfebf0b1c in sltstcu () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#1  0xfe57aa24 in kpusattr () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#2  0xc03fc in _oci_close_session (session=0x3f3200)
    at /data/src/php4-STABLE-200307080530/ext/oci8/oci8.c:2410
#3  0xbbda8 in _oci_session_list_dtor (rsrc=0x374a58)
    at /data/src/php4-STABLE-200307080530/ext/oci8/oci8.c:935
#4  0x91790 in list_entry_destructor (ptr=0x374a58)
    at /data/src/php4-STABLE-200307080530/Zend/zend_list.c:177
#5  0x8e7ec in zend_hash_apply_deleter (ht=0x28bb4c, p=0x4b3df0)
    at /data/src/php4-STABLE-200307080530/Zend/zend_hash.c:598
#6  0x8eb5c in zend_hash_graceful_reverse_destroy (ht=0x28bb4c)
    at /data/src/php4-STABLE-200307080530/Zend/zend_hash.c:664
#7  0x91984 in zend_destroy_rsrc_list (ht=0x28bb4c)
    at /data/src/php4-STABLE-200307080530/Zend/zend_list.c:233
#8  0x755bc in shutdown_executor ()
    at /data/src/php4-STABLE-200307080530/Zend/zend_execute_API.c:213
#9  0x85878 in zend_deactivate ()
    at /data/src/php4-STABLE-200307080530/Zend/zend.c:666
#10 0x3c3b4 in php_request_shutdown (dummy=0x0)
    at /data/src/php4-STABLE-200307080530/main/main.c:995
#11 0xa552c in apache_php_module_main (r=0x34ab58, display_source_mode=0)
    at /data/src/php4-STABLE-200307080530/sapi/apache/sapi_apache.c:60
#12 0x30fa8 in send_php ()
---Type <return> to continue, or q <return> to quit---
#13 0x31018 in send_parsed_php ()
#14 0x1ed94c in ap_invoke_handler ()
#15 0x20e2f0 in process_request_internal ()
#16 0x20e37c in ap_process_request ()
#17 0x200630 in child_main ()
#18 0x2009d4 in make_child ()
#19 0x200aec in startup_children ()
#20 0x201514 in standalone_main ()
#21 0x2021ac in main ()



All subsequent occurrences have this backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xfe3428d4 in t_splay () from /usr/lib/libc.so.1
(gdb) bt
#0  0xfe3428d4 in t_splay () from /usr/lib/libc.so.1
#1  0xfe342740 in t_delete () from /usr/lib/libc.so.1
#2  0xfe342344 in realfree () from /usr/lib/libc.so.1
#3  0xfe342b84 in _free_unlocked () from /usr/lib/libc.so.1
#4  0xfe342ad4 in free () from /usr/lib/libc.so.1
#5  0xfe823230 in nlad_destroy_node ()
   from /opt/ora920/ora920/lib/libclntsh.so.9.0
#6  0xfe82320c in nlad_destroy_node ()
   from /opt/ora920/ora920/lib/libclntsh.so.9.0
#7  0xfe822424 in nladtrm () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#8  0xfe71fe50 in nsopen_cleanup ()
   from /opt/ora920/ora920/lib/libclntsh.so.9.0
#9  0xfe71f83c in nsclose () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#10 0xfe702ec4 in nsdisc () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#11 0xfe7a9bc8 in nioqds () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#12 0xfe53abbc in upidhs () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#13 0xfe55dcb0 in kpudtch () from /opt/ora920/ora920/lib/libclntsh.so.9.0
#14 0xc0bbc in _oci_close_server (server=0x323790)
    at /data/src/php4-STABLE-200307080530/ext/oci8/oci8.c:2595
#15 0xbbd60 in _oci_server_list_dtor (rsrc=0x7bb930)
    at /data/src/php4-STABLE-200307080530/ext/oci8/oci8.c:921
#16 0x91790 in list_entry_destructor (ptr=0x7bb930)
    at /data/src/php4-STABLE-200307080530/Zend/zend_list.c:177
---Type <return> to continue, or q <return> to quit---
#17 0x8e7ec in zend_hash_apply_deleter (ht=0x28bb4c, p=0x49b508)
    at /data/src/php4-STABLE-200307080530/Zend/zend_hash.c:598
#18 0x8eb5c in zend_hash_graceful_reverse_destroy (ht=0x28bb4c)
    at /data/src/php4-STABLE-200307080530/Zend/zend_hash.c:664
#19 0x91984 in zend_destroy_rsrc_list (ht=0x28bb4c)
    at /data/src/php4-STABLE-200307080530/Zend/zend_list.c:233
#20 0x755bc in shutdown_executor ()
    at /data/src/php4-STABLE-200307080530/Zend/zend_execute_API.c:213
#21 0x85878 in zend_deactivate ()
    at /data/src/php4-STABLE-200307080530/Zend/zend.c:666
#22 0x3c3b4 in php_request_shutdown (dummy=0x0)
    at /data/src/php4-STABLE-200307080530/main/main.c:995
#23 0xa552c in apache_php_module_main (r=0x34abb8, display_source_mode=0)
    at /data/src/php4-STABLE-200307080530/sapi/apache/sapi_apache.c:60
#24 0x30fa8 in send_php ()
#25 0x31018 in send_parsed_php ()
#26 0x1ed94c in ap_invoke_handler ()
#27 0x20e2f0 in process_request_internal ()
#28 0x20e37c in ap_process_request ()
#29 0x200630 in child_main ()
#30 0x2009d4 in make_child ()
#31 0x200f40 in perform_idle_server_maintenance ()
#32 0x20182c in standalone_main ()
---Type <return> to continue, or q <return> to quit---
#33 0x2021ac in main ()





Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-07-08 05:02 UTC] Manfred dot Metz at rsd dot rohde-schwarz dot com
After switching to persistant OCI connections the error seems to be gone?!?!?!?!?!
 [2003-07-10 00:16 UTC] Manfred dot Metz at rsd dot rohde-schwarz dot com
Ok. Here is the unified diff


/usr/local/bin/diff -u php4-STABLE-200307080530/ext/oci8/oci8.c php-4.3.3RC2-dev/ext/oci8/oci8.c
--- php4-STABLE-200307080530/ext/oci8/oci8.c    2003-05-02 11:05:44.000000000 +0200
+++ php-4.3.3RC2-dev/ext/oci8/oci8.c    2003-07-08 12:57:41.150024000 +0200
@@ -2153,6 +2153,8 @@
        oci_session *session = 0, *psession = 0;
        OCISvcCtx *svchp = 0;
        char *hashed_details;
+       struct timeval tv;
+       int sec, usec;
 #ifdef HAVE_OCI_9_2
        ub2 charsetid = 0;
 #endif
@@ -2167,6 +2169,7 @@
           but only as pesistent requested connections will be kept between requests!
        */

+       if (! exclusive) {
        hashed_details = (char *) malloc(strlen(SAFE_STRING(username))+
                                                                         strlen(SAFE_STRING(password))+
                                                                         strlen(SAFE_STRING(server->dbname))+1);
@@ -2176,7 +2179,6 @@
                        SAFE_STRING(password),
                        SAFE_STRING(server->dbname));

-       if (! exclusive) {
                zend_hash_find(OCI(user), hashed_details, strlen(hashed_details)+1, (void **) &session);

                if (session) {
@@ -2191,6 +2193,15 @@
                                /* breakthru to open */
                        }
                }
+       } else {
+       gettimeofday((struct timeval *) &tv, (struct timezone *) NULL);
+       sec = (int) tv.tv_sec;
+       usec = (int) (tv.tv_usec % 1000000);
+       /* The max value usec can have is 0xF423F, so we use only five
+        hex digits for usec and eigth hex digits for sec. */
+       hashed_details = (char *) malloc(8+5+1); /* always enough */
+       sprintf(hashed_details, "%08x%05x", tv.tv_sec, tv.tv_usec);
+
        }

        session = calloc(1,sizeof(oci_session));
@@ -2679,7 +2690,7 @@
                persistent = 0;
        } else {
                /* if our server-context is not persistent we can't */
-               persistent = server->persistent;
+               persistent = server->persistent ? persistent : 0;
        }

        session = _oci_open_session(server,username,password,persistent,exclusive,charset);
 [2003-11-27 01:10 UTC] sniper@php.net
See bug #26393, there it's said that this patch does not fix the problem..

 [2003-12-03 01:07 UTC] editor at tinnes dot com
Could you tell me the status of this issue? Its a showstopper for my development (See bug #26393)
 [2003-12-05 05:17 UTC] Manfred dot Metz at rsd dot rohde-schwarz dot com
I'm still using the php version 4.3.3-RC2-STABLE-200307080530 with this patch applied together with apache 1.3.27. 

There are no problems with non persistant Oracle connections. 

There are problems with persistant Oracle connections because the reuse of existing connections does not work properly and so the limit of parallel database connections to Oracle will be reached after a while. 

So we also use non persistant connections. In January 2004 we plan to move to the latest versions of apache 1.3 and to php-4.3.4 then i will be able to see what happens.
 [2003-12-05 10:30 UTC] walovaton at yahoo dot com dot mx
I'm almost sure I have the very same problem.  I managed to reproduce the error in my development machine using Apache 1.3.28, PHP 4.3.3, Oracle 8.1.7.  The production environtment is the same but uses Oracle 9.2.0 instead.

Operating Systems:
- Devel Machine: Mandrake 9.1 (Kernel 2.4.19)
- Production Machine: RedHat 9.0 (Kernel 2.4.20 SMP)

I used this configure options in Apache:
./configure --prefix=/usr/local/apache \
            --enable-module=most \
            --enable-shared=max

And this ones in PHP:
./configure --prefix=/usr/local/php-4.3.3-debug \
            --with-apxs=/usr/local/apache/bin/apxs \
            --with-config-file-path=/usr/local/php-4.3.3-debug/etc \
            --enable-shared \
            --disable-static \
            --enable-debug \
            --disable-rpath \
            --enable-pic \
            --enable-inline-optimization \
            --enable-track-vars \
            --with-versioning \
            --with-mod_charset \
            --with-regex=php \
            --enable-trans-sid \
            --enable-safe-mode \
            --with-zlib \
            --enable-bcmath=shared \
            --enable-calendar=shared \
            --with-dom=shared \
            --with-dom-xslt=shared \
            --with-dom-exslt=shared \
            --with-xmlrpc=shared \
            --enable-ftp=shared \
            --with-gettext=shared \
            --with-mysql=shared,/usr \
            --enable-shmop=shared \
            --enable-sysvmsg=shared \
            --enable-sysvsem=shared \
            --enable-sysvshm=shared \
            --with-bz2=shared \
            --with-tsrm-pthreads \
            --with-oci8=shared \
            --with-fdftk=shared,/usr

Please, note the --enable-debug  ;-)

I reproduced the problem this way: Configured the Apache directive MaxRequestPerChild to a very low value, let's say 30. then started Apache normally.

Then use GDB to track some httpd processes (I did this as root):
# gdb /usr/local/apache/bin/httpd <some-httpd-pid>

make gdb to continue the execution.

With a browser access a php page that establish an Oracle connection.  The problem show up with both, persistant and non-persistant connections.

Reload the page several times until the process being debuged terminates (due to the MaxRequestPerChild directive) and kaput! Segmentation Fault!

The backtrace I got is the following:
Program received signal SIGSEGV, Segmentation fault.
0x40f0645c in epc_exit_handler () from
/opt/OraHome81/lib/libclntsh.so.8.0
(gdb) bt
#0  0x40f0645c in epc_exit_handler () from
/opt/OraHome81/lib/libclntsh.so.8.0
#1  0x400d6ac1 in exit () from /lib/i686/libc.so.6
#2  0x0805c823 in clean_child_exit ()
#3  0x0805f672 in child_main ()
#4  0x0805fcc8 in make_child ()
#5  0x08060010 in perform_idle_server_maintenance ()
#6  0x0806062e in standalone_main ()
#7  0x08060c34 in main ()
#8  0x400c3082 in __libc_start_main () from /lib/i686/libc.so.6

The problem occurs only when the process terminates, so the web user isn't affected by this problem at all.

Now, debugging a process that doesn't establish an Oracle connection (even with the oci8 extension loaded), when the process terminates, gdb says: "Program exited normally."

Due to the high traffic in the production machine, this Segmentation falut is logged every five seconds average.

I hope this information helps to solve the problem.


-William
 [2003-12-12 07:58 UTC] phanto@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

fixed in pecl
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Jun 22 16:01:29 2024 UTC