PHP :: Bug #15156 :: apache segmentation fault (11) with php4

Bug #15156

apache segmentation fault (11) with php4

Submitted:

2002-01-22 03:00 UTC

Modified:

2002-03-17 00:00 UTC

Votes:	7
Avg. Score:	4.3 ± 0.9
Reproduced:	7 of 7 (100.0%)
Same Version:	3 (42.9%)
Same OS:	2 (28.6%)

From:

cummings at cmgm dot stanford dot edu

Assigned:

Status:

No Feedback

Package:

Reproducible crash

PHP Version:

4.1.1

OS:

RedHat Linux, 2.4.2 kernel

Private report:

CVE-ID:

None

View Developer Edit

[2002-01-22 03:00 UTC] cummings at cmgm dot stanford dot edu

I recently installed PHP4 from the tarball distribution as a dynamically loaded module for Apache.  It builds cleanly and the server starts.  However, I have two serious problems with my server:

  1) all requests to the server for .html documents result in a "[notice] child pid 15202 exit signal Segmentation fau
lt (11)" error

  2) requests for PHP-containing documents do not return anything to the server.  However, an examination of the source shows the text of the document with <?php... tags.

If I comment out the LoadModule directive that loads PHP4 in httpd.conf, my server can process the html document requests.

PHP 4.1.1 was configured with:
  --enable-debug
  --with-mysql=/usr
  --with-apxs=/usr/sbin/apxs

Apache is apache-1.3.22-3 installed from a RawHide RPM

MySQL is MySQL-4.0.1-2 installed from a MySQL RPM

Here's the gdb backtrace from a request for a non-PHP-including html document:

--------------------------------------
Starting program: /usr/sbin/httpd -X -f /etc/httpd/conf/httpd.conf
(no debugging symbols found)...[New Thread 1024 (LWP 15221)]

(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 15221)]
0x40480108 in php_xbithack_handler (r=0x80df818) at mod_php4.c:777
777             conf = (php_apache_info_struct *) get_module_config(r->per_dir_c
onfig, &php4_module);
(gdb)
(gdb) bt
#0  0x40480108 in php_xbithack_handler (r=0x80df818) at mod_php4.c:777
#1  0x8054f7a in ap_invoke_handler ()
#2  0x8068e73 in ap_some_auth_required ()
#3  0x403d9ea4 in handle_dir () from /etc/httpd/modules/mod_dir.so
#4  0x8054f7a in ap_invoke_handler ()
#5  0x8068e73 in ap_some_auth_required ()
#6  0x806910e in ap_process_request ()
#7  0x806113d in ap_child_terminate ()
#8  0x80613c2 in ap_child_terminate ()
#9  0x8061449 in ap_child_terminate ()
#10 0x80620aa in ap_child_terminate ()
#11 0x8062434 in main ()
#12 0x40171108 in __libc_start_main () from /lib/i686/libc.so.6
--------------------------------------

I'd appreciate any help you can provide on this.  By the way, I'm willing to use an older version of PHP if the bug is fixed there.  Thanks a lot.

Best regards,

Craig

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2002-01-22 18:40 UTC] cummings at cmgm dot stanford dot edu

Update:

I just tried to reinstall using slightly older releases of MySQL and PHP.  However, the problem persists.  Requests for HTML cause segfault, requests for PHP return unprocessed document text.  Latest installed versions are:

PHP 4.0.6
MySQL 3.23.47

[2002-01-24 13:03 UTC] cummings at cmgm dot stanford dot edu

I've tried versions of PHP all the way back to 3.0.18 and I still get the same problems.

[2002-01-24 21:01 UTC] yohgaki@php.net

Turn off xbit hack ini directive to see if it helps.
BTW, xbit hack works fine for me. (4.2.0-dev. It worked older versions also)

Are you using PHP CGI version also?
Are you using PHP3 AND PHP4 as module?
What is "AddType" setting for PHP. (In httpd.conf)

[2002-01-30 14:29 UTC] cummings at cmgm dot stanford dot edu

Sorry if this is a stupid question but how do I turn off the xbit hack directive?

Here are the answers to your questions:

1) I followed directions for an Apache module installation.  If PHP4 is installed as a CGI version as well, then I am not aware of it.  How can I confirm that the CGI version is not installed? 

2) PHP3 was installed on this machine as part of the RedHat 7.1 distribution.  I removed it (rpm -e php) prior to installing PHP4.  Should I check for some remnant of the previous installation that might be causing a conflict?

3) Here are the relevant lines from my httpd.conf file

<IfModule mod_php4.c>
  AddType application/x-httpd-php .php4 .php3 .phtml .php
  AddType application/x-httpd-php-source .phps
</IfModule>

# The following is for PHP3:
<IfModule mod_php3.c>
  AddType application/x-httpd-php3 .php3
  AddType application/x-httpd-php3-source .phps
</IfModule>

# The following is for PHP/FI (PHP2):
<IfModule mod_php.c>
  AddType application/x-httpd-php .phtml
</IfModule> 

Thanks again.

Craig

[2002-01-31 18:55 UTC] cummings at cmgm dot stanford dot edu

In spite of my prior 'make clean' commands, I found that copies of libphp3.so and libphp4.so were present on my system.  I deleted these files and reinstalled PHP 4.1.1 from a fresh tarball distribution (configuration options as before).  I also scrutinized my httpd.conf file and found that 'LoadModule libphp4.so' appeared twice, each with a different path.  In order to satisfy apache, I had previously created a symbolic link from the second directory to modules/libphp4.so.  I subsequently deleted the symbolic link and the Apache directive that refered to it.

I continue to have the problems but there are some differences.  The server starts fine.  Documents with .html or .php extensions fail to load in the browser and result in a child process segmentation fault in the error_log.  Occasionally, one browser request results in multiple child seg. faults.

I tried to get a backtrace but strangely, when I run httpd with the -X flag, the server does not crash.  However, PHP code is not processed.  The core file is nowhere to be found.

Incidentally, commenting out the AddModule directive: 

   ...
   LoadModule php4_module        modules/libphp4.so
   ...
   # AddModule mod_php4.c
   ...

restores functionality to the server (without PHP enabled).

Scripts in the cgi-bin directory seem to work fine and text documents (with .txt extensions) load fine from the html directory.

Any advice?

[2002-02-01 00:31 UTC] yohgaki@php.net

I suggest you to install from scrach (including all config files related)
Make sure you do "rpm -e" for all apache/php related package including -devel one. Delete or move all httpd.conf/php.ini.

If you still have segfault problem, report it again.

[2002-02-01 20:10 UTC] cummings at cmgm dot stanford dot edu

I did as you suggested.  New apache and apache-devel rpms.  Then installed PHP 4.1.1   All is well regarding segmentation faults.  However, in order to get apache to process the embedded php code, I had to slightly modify the httpd.conf file. 

This was the code that didn't work:

<IfModule mod_php4.c>
  AddType application/x-httpd-php .php4 .php3 .phtml .php
  AddType application/x-httpd-php-source .phps
</IfModule>
 
# The following is for PHP3:
<IfModule mod_php3.c>
  AddType application/x-httpd-php3 .php3
  AddType application/x-httpd-php3-source .phps
</IfModule>

# The following is for PHP/FI (PHP2):
<IfModule mod_php.c>
  AddType application/x-httpd-php .phtml
</IfModule>

I moved the AddType directives outside of the <IfModule mod_php4.c> block and now it works.  

Thanks for your help!

[2002-02-02 19:08 UTC] yohgaki@php.net

> <IfModule mod_php4.c>
>   AddType application/x-httpd-php .php4 .php3 .phtml .php
>   AddType application/x-httpd-php-source .phps
> </IfModule>
>  
> # The following is for PHP3:
> <IfModule mod_php3.c>
>   AddType application/x-httpd-php3 .php3
>   AddType application/x-httpd-php3-source .phps
> </IfModule>
> 
> # The following is for PHP/FI (PHP2):
> <IfModule mod_php.c>
>   AddType application/x-httpd-php .phtml
> </IfModule>

You *CANNOT* specify the same extension for PHP4/PHP3/PHPFI.
Just don't do that, then it should work.

We cannot anything for it, probably.
(i.e. It's simply does not work and there may not be good way to prevend segfault for such configuration)

[2002-03-17 00:00 UTC] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a month, 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".

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2025 The PHP Group All rights reserved.	Last updated: Mon May 05 21:01:29 2025 UTC