php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #30412 Apache Segmentation Fault (11)
Submitted: 2004-10-12 17:22 UTC Modified: 2005-03-09 21:48 UTC
Votes:11
Avg. Score:4.5 ± 0.8
Reproduced:10 of 10 (100.0%)
Same Version:4 (40.0%)
Same OS:3 (30.0%)
From: subscription at nazarenko dot net Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 5.0.4-Dev OS: SuSE Linux 8.2
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: subscription at nazarenko dot net
New email:
PHP Version: OS:

 

 [2004-10-12 17:22 UTC] subscription at nazarenko dot net
Description:
------------
Very similar to Bug #30410.

ocilogon() causes Apache to crash with Segmentation Fault 11. The crashes do not happen EVERY time, however around 90% of page loads are unsuccessful.

Machine config:

* 2xCPU Intel arch
* SuSE 8.2 with 2.40.20-SMP kernel
* Apache 2.0.52 - Prefork
* Oracle Client 9.2.0
* PHP 5.0.2 with OCI8 support compiled in.

Full configure command: 

./configure \
--prefix=/usr/lib/apache2-prefork 
--datadir=/usr/share/php \
--bindir=/usr/bin \
--libdir=/usr/share \
--with-config-file-path=/etc/php \
--with-exec-dir=/etc/php/exec \
--enable-bcmath \
--enable-calendar \
--enable-discard-path \
--enable-exif \
--enable-force-cgi-redirect \
--enable-ftp  \
--enable-magic-quotes \
--enable-mbstring \
--enable-memory-limit \
--enable-safe-mode \
--enable-shmop \
--enable-sigchild  \
--enable-sysvsem \
--enable-sysvshm \
--enable-versioning \
--enable-wddx \
--with-bz2 \
--with-dom \
--with-ftp \
--with-gettext \
--with-gmp \
--with-jpeg-dir=/usr \
--with-mcal=/usr \
--with-mcrypt \
--with-mysql=/usr/lib/mysql \
--with-mysql-sock=/srv/mysql/mysql.sock \
--with-png-dir=/usr \
--with-tiff-dir=/usr \
--with-xml \
--with-xpm-dir \
--with-zlib \
--with-openssl \
--with-iconv \
--with-oci8=/home/oracle/OraHome1 \
--with-apxs2=/usr/sbin/apxs2-prefork \
--with-gd \
--enable-gd-native-ttf \
--with-ttf \
--with-freetype-dir \
--enable-pcntl

Expected result:
----------------
There are a couple of pecularities:

* When I tried to run httpd2 with -X parameter from the command line, I noticed that there was only one thread started (I presume this is normal). However, after that I could never cause the Apache to crash again. Only with multiple threads this was true. In order to generate the backtrace I run "httpd2 -X" within the gdb session.

* PHP 4.3.x versions work absolutely fine with exactly the same configuration without any crashes.

* Both PHP4 and PHP5 exhibit "segfaults (11)" messages when apache-worker MPM is used. See bug #28603 that I reported some time ago. I believe this might be somehow connected, but whereas in the past OCI8 was not correctly working only with the worker MPM, it now crashes even with the prefork MPM, making it impossible to run in a productive environment.

Actual result:
--------------
gdb backtrace:

(gdb) run -X -f /etc/apache2/httpd.conf
Starting program: /usr/sbin/httpd2-prefork -X -f /etc/apache2/httpd.conf
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 16384 (LWP 13424)]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 13424)]
0x40edae91 in snauca_check_adapter () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
(gdb) bt
#0  0x40edae91 in snauca_check_adapter () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#1  0x40ed9614 in nau_viat () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#2  0x40ed290c in nau_gettab () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#3  0x40ed0f8b in nau_ini () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#4  0x40ec68f3 in nainit () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#5  0x40e7af77 in nsnainit () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#6  0x40e702ba in nsopen () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#7  0x40e593d9 in nscall1 () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#8  0x40e58910 in nscall () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#9  0x40eef934 in niotns () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#10 0x40eeb649 in nigcall () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#11 0x40e88b93 in osncon () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#12 0x40cc4913 in kpuadef () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#13 0x40d47ae5 in upiini () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#14 0x40d36e3b in upiah0 () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#15 0x40c9eed6 in kpuatch () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#16 0x40d2afbc in OCIServerAttach () from /home/oracle/OraHome1/lib/libclntsh.so.9.0
#17 0x405d241b in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#18 0x405d2fcb in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#19 0x405da68e in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#20 0x40753368 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#21 0x40753ae1 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#22 0x4074f95e in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#23 0x4072b9c5 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#24 0x406e5360 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#25 0x4075c906 in COMP_str_reasons () from /usr/lib/apache2-prefork/libphp5.so
#26 0x08069bb8 in ap_run_handler ()
#27 0x0806a2c9 in ap_invoke_handler ()
#28 0x080664d8 in ap_process_request ()
#29 0x08060f3e in ap_process_http_connection ()
#30 0x08075248 in ap_run_process_connection ()
#31 0x0807562e in ap_process_connection ()
#32 0x08067e74 in child_main ()
#33 0x08068022 in make_child ()
#34 0x0806813c in startup_children ()
#35 0x0806899d in ap_mpm_run ()
#36 0x0806fd0f in main ()
#37 0x402148ae in __libc_start_main () from /lib/libc.so.6
(gdb)


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-10-12 17:28 UTC] tony2001@php.net
Looks like another pretty OCI segfault to me.
If it's true - there is nothing I can do with it.
Try to install appropriate patches for your Oracle installation.
Also you may want try it with Apache 1.3.x, there is a possibility that OCI libs have some problems with thread safety.
 [2004-10-12 20:31 UTC] mail-list at nazarenko dot net
How can it be explained that I do not get those segfaults with the same configuration and PHP 4.3.x, but get them with PHP 5.0.x ?
 [2004-10-13 19:11 UTC] mail-list at nazarenko dot net
Please have a look at the bug #30412.
The person who reported it has exactly the same problem.

He confirms my experience -- the segfaults do not happen with 4.3.9 but are present with 5.0.2
 [2004-10-13 19:12 UTC] mail-list at nazarenko dot net
Sorry, I meant the bug #30410.
 [2004-12-02 01:20 UTC] tony2001@php.net
>[Thu Dec 02 00:57:47 2004] [warn] child process 18167 still did not exit, sending a SIGTERM
I don't think PHP/OCI8 is causing this.
I saw this problem many times without OCI8 enabled or even without any module enabled at all.

>Some page loads are unsuccessful, but there
>is no segfault! The browser just keeps waiting and waiting 
>and nothing

I would be very thankful if you provide tiny reproduce script, that I can use to reproduce your problem.
happens.
 [2004-12-02 15:17 UTC] subscription at nazarenko dot net
Let me confirm it again after some more testing today that I still do get segfaults, but not that often than before.

Also, let me point out that it seems to be exclusively Apache/PHP problem. The same script is run from the shell environment with no problems at all.

Now to the example that you have asked for. It is really simple. In fact *any* Oracle query will cause occasional browser "hanging". Here is a bit of code I used today for testing:

<?php

$db_conn = ocilogon( "user", "password", "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myoracle)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=CRPT)))")
         or die("Critical Error: No connection to Oracle!");

$cmdstr = "
	SELECT DISTINCT
		TRIM(XM.X_MEMBER_ID)  MEMBER_ID,
		S.X_MEMBER_ID            DBS_ID
	FROM
		TABLE_SITE_PART              SP,
		TABLE_SITE_PART             SP2,
		TABLE_X_MEMBERDATA           XM,
		TABLE_SITE                    S
	WHERE
		SP2.X_CLASS_KEY = 9
		AND SP2.LEVEL_TO_BIN IN (0,1,2,3,4,5)
		AND SP2.SITE_PART2SITE_PART = SP.OBJID
		AND SP2.X_SITE_PART2MEMBERDATA = XM.OBJID
		AND SP.ALL_SITE_PART2SITE = S.OBJID
		AND XM.X_STATUS = 'Active'
		AND S.STATUS = '0'
	ORDER BY
		TRIM(XM.X_MEMBER_ID)
";
$parsed = ociparse($db_conn, $cmdstr);
ociexecute($parsed);
$boxrows = ocifetchstatement($parsed, $listbox);
OCIFreeStatement($parsed);

print_r($listbox);

?>


Most of the times this would work fine returning me an array of data. But sometimes the browser would just wait with nothing happening. And very rarely the page would fail immediately (producing a segfault in apache's error log)

Hope this helps.
 [2005-01-13 01:27 UTC] tony2001@php.net
Please, try latest snapshot with non-threaded Apache.
Are you still able to replicate the problem ?
 [2005-02-10 21:17 UTC] subscription at nazarenko dot net
Hello it is me again,

Tested both 5.0.3 release and the latest snapshot php5-STABLE-200502101130 with both Apache 2.0.52 Prefork and Worker MPMs.

5.0.3 and the snapshot behave identically.

Under Prefork MPM everything is 100% ok.

Under Worker the same problem as before: some page loads are unsuccessful with no segfault. The browser just keeps waiting and waiting and nothing happens. This happens on
average for 30% of page requests containing Oracle queries.

Don't know if you want to pursue this further as the Prefork works fine now.

Many thanks for your time and effort!!
 [2005-02-10 21:34 UTC] tony2001@php.net
Please check that you have set all environments variables (i.e. ORACLE_HOME, TNS_ADMIN etc) properly.
 [2005-02-16 04:44 UTC] subscription at nazarenko dot net
TNS_ADMIN is not used, since I do not utilize tnsnames.ora file. As you can see from the code example I use the connection description string directly in the script:

<?php
$db_conn = ocilogon( "user", "password", "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=myoracle)(PORT=
1521)))(CONNECT_DATA=(SERVICE_NAME=CRPT)))");
?>

ORACLE_HOME is definitely set, otherwise there will be no successful queries at all.
 [2005-04-29 16:53 UTC] pumuckel at metropolis dot de
The segfaults are reproducable on our machine with only a ocilogon(...) call.

The segfaults occur ONLY, if the connection gets destroyed by the automatic variable clean up process after executing the script.

When unset($conn) is called before, everything works fine.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Aug 16 10:05:45 2022 UTC