php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15499 Apache crashes with Segmentation fault
Submitted: 2002-02-11 07:09 UTC Modified: 2002-04-18 13:39 UTC
Votes:29
Avg. Score:4.9 ± 0.5
Reproduced:29 of 29 (100.0%)
Same Version:21 (72.4%)
Same OS:13 (44.8%)
From: mbretter at jawa dot at Assigned:
Status: Closed Package: OCI8 related
PHP Version: 4.1.1 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mbretter at jawa dot at
New email:
PHP Version: OS:

 

 [2002-02-11 07:09 UTC] mbretter at jawa dot at
We run many sites with php4 and oracle.
On every site we have seen that Apache child processes crash after about 10 to 20 requests.
We use different Linux Versions (RedHat 7.1, SuSe Linux 7.1, 7.3) and also different php-Versions (php4.0.6, php4.1.1).
All these sites use Oracle as Database (oci8-Module).
We run other sites with PHP but without Oracle-Module and these sites run stable.
We tried also PHP on W2K with IIS with the ISAPI Module with Oci8-Support and we have the same effect, after 10 to 20 requests, the Server stops serving PHP-Sites, ...
... this seems to be a bug in the oci8-Module of php.

below ldd of http and a gdb backtrace.
phpinfo can be requested from this url: http://sqp.sft.jawa.at/test.php

ldd httpd
        libdl.so.2 => /lib/libdl.so.2 (0x40027000)
        libm.so.6 => /lib/libm.so.6 (0x4002a000)
        libldap.so.1 => /usr/lib/libldap.so.1 (0x40048000)
        liblber.so.1 => /usr/lib/liblber.so.1 (0x4005d000)
        libgd.so => /usr/local/lib/libgd.so (0x40062000)
        libt1.so.1 => /usr/local/lib/libt1.so.1 (0x4009d000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x400e0000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x40116000)
        libz.so.1 => /usr/local/lib/libz.so.1 (0x40142000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40151000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40170000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4019e000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x401af000)
        libclntsh.so.8.0 => /opt/oracle/OraHome1/lib/libclntsh.so.8.0 (0x401c5000)
        libc.so.6 => /lib/libc.so.6 (0x4077b000)
        libwtc8.so => /opt/oracle/OraHome1/lib/libwtc8.so (0x4088f000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40891000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

gdb output:

pluto:/usr/local/apache/bin # gdb httpd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-suse-linux"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
[New Thread 1024 (LWP 7211)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 7211)]
0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11, pData=0xbfffea98)
    at zend_hash.c:935
935                     if ((p->h == h) && (p->nKeyLength == 0)) {
(gdb) bt
#0  0x8159933 in zend_hash_index_find (ht=0x822ca44, h=11, pData=0xbfffea98)
    at zend_hash.c:935
#1  0x815a54b in _zend_list_delete (id=11) at zend_list.c:53
#2  0x80aa637 in _oci_column_hash_dtor (data=0x8f0db04) at oci8.c:727
#3  0x815894a in zend_hash_destroy (ht=0x87db67c) at zend_hash.c:541
#4  0x80aa7f8 in _oci_stmt_list_dtor (rsrc=0x87db4b4) at oci8.c:771
#5  0x815a838 in list_entry_destructor (ptr=0x87db4b4) at zend_list.c:177
#6  0x815aa67 in zend_destroy_rsrc_list (ht=0x822ca44) at zend_list.c:248
#7  0x8148f97 in shutdown_executor () at zend_execute_API.c:196
#8  0x8152d84 in zend_deactivate () at zend.c:600
#9  0x806d71f in php_request_shutdown (dummy=0x0) at main.c:735
#10 0x815f596 in apache_php_module_main (r=0x828fe44, display_source_mode=0)
    at sapi_apache.c:96
#11 0x806ac3e in send_php ()
#12 0x806aca6 in send_parsed_php ()
#13 0x8184509 in ap_invoke_handler ()
#14 0x8199f6f in process_request_internal ()
#15 0x8199fe2 in ap_process_request ()
#16 0x8190b96 in child_main ()
#17 0x8190d55 in make_child ()
#18 0x8190ed6 in startup_children ()
#19 0x819157d in standalone_main ()
#20 0x8191ddc in main ()
#21 0x40797baf in __libc_start_main () from /lib/libc.so.6

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-13 09:55 UTC] canning at colltech dot com
We see this same problem on Redhat 6.2 kernel version 2.2.19-6.3.  We are using version 8.1.6.2 of the oracle client libraries with php 4.0.6 and php 4.1.1.
 [2002-02-20 12:37 UTC] mbretter at jawa dot at
We use Oracle 8.1.7

this described bug is completely reproduceable.

We store in our App the session-data in a db-table in a CLOB. Maybe there is a problem with the LOB-Handling of the OCI8-Module.

I hope this bug will be edited soon, because we have real problems with our customers.

We can also give root-access via ssh to our server for debugging.
 [2002-03-12 08:16 UTC] mranner at jawa dot at
We need urgent support on this case!
What can we do to accellerate the necessary steps?

Sincerly,

Mike
 [2002-03-12 08:24 UTC] sander@php.net
You can try to fix it yourself...
If you've fixed it, please post a diff here or send it to php-dev@lists.php.net.
 [2002-03-12 08:25 UTC] derick@php.net
Can you possible try a snapshot from snaps.php.net?

Derick
 [2002-03-12 08:30 UTC] mbretter at jawa dot at
I already tried the latest version from cvs
/* $Id: oci8.c,v 1.168 2002/02/10 12:41:52 thies Exp $ */
and 
/* $Id: php_oci8.h,v 1.23 2002/02/10 12:41:52 thies Exp $ */

with the same effect
 [2002-03-12 08:48 UTC] mbretter at jawa dot at
We will pay for the support if the bug can be fixed from  one of the php-developers.

I think the maintainer of this module will find the bug more quickly.
 [2002-03-28 04:08 UTC] mbretter at jawa dot at
Now I upgradet from Oracle 8.1.7 to Oracle 8.1.7.3, recompiled    
 php and apache (4.1.2) with no effect. The crash still exists. 

It seems that nobody of the php-team feels responsible for improvements in the oci8-module!?
 [2002-04-13 09:15 UTC] thies@php.net
please try to send me a short _selfcontained_ script that reproduces that problem when hitting apache with ab.

i'm very busy right now. please contact me directly - money can raise the priority of this problem on my TODO list.

 [2002-04-18 13:39 UTC] thies@php.net
This bug has been fixed in CVS.

 
 [2002-04-23 14:20 UTC] mbretter at jawa dot at
The fix seems to solve also crashes after 10 or 20 requests.

Now our production-server runs for 3 days without crashing.

For all others wich have the same problem: 

The files wich has been changed are under the Zend dir:
zend_list.c
zend_list.h
zend_hash.c
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 12:01:27 2024 UTC