php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18258 Gettting frequent Seg Faults on PHP scripts
Submitted: 2002-07-10 03:54 UTC Modified: 2002-10-15 01:00 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: tauren at servlets dot net Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 4.2.1 OS: Red Hat 6.2
Private report: No CVE-ID: None
 [2002-07-10 03:54 UTC] tauren at servlets dot net
I just upgraded to Apache 1.3.26 with PHP 4.2.1 and now I'm having problems with Segmentaion Faults when going to PHP pages.  Previous to upgrading, my Apache/PHP server was running with all of the same options that I'm compiling in now.  I wasn't having problems with the Apache 1.3.24/PHP4.2.0 combination.

For instance, I have a simple document called phpinfo.php that contains the following:
  <?php
     phpinfo();
  ?>

When I hit this page, I will normally get the text output, but sometimes my browser will come back with no data or an error.  Most of the time the two images (PHP and Zend) will not display.  When this happens, the following errors are appended to the error_log:

[Wed Jul 10 00:38:43 2002] [notice] child pid 1295 exit signal Segmentation fault (11)
[Wed Jul 10 00:38:46 2002] [notice] child pid 1298 exit signal Segmentation fault (11)

I've recompiled Apache and PHP with the --enable-debug option.  Here is how PHP is configured:

CPPFLAGS=-I/usr/local/include
LDFLAGS=-L/usr/local/lib
./configure --prefix=/usr/local \
  --with-apache=/home/local/src/atb/Apachetoolbox-1.5.58/apache_1.3.26 \
--enable-exif \
--enable-track-vars \
--with-calendar=shared \
--enable-magic-quotes \
--enable-trans-sid \
--enable-wddx \
--enable-ftp \
--enable-inline-optimization \
--enable-memory-limit \
--enable-debug \
--with-gd="/usr/local" \
--with-zlib \
--enable-gd-native-tt \
--with-t1lib="/usr/local" \
--with-jpeg-dir="/usr" \
--with-png-dir="/usr" \
--with-zlib-dir="/usr" \
--with-ttf \
--with-freetype-dir="/usr/local" \
 --with-imap=/usr/local \
 --with-mhash=/usr/local \
 --with-mcrypt=/usr/local \
 --with-openssl="/usr/local" \
 --with-curl=/usr/local \
 --with-gettext="/usr" \
 --with-mysql=/usr \
 --with-ldap \

Here is how Apache is configured:

export SSL_BASE=/usr/local
export EAPI_MM=/home/local/src/atb/Apachetoolbox-1.5.58/src/mm-1.1.3
export CFLAGS=""
export LIBS=""
export INCLUDES=""
./configure --prefix=/usr/local/apache \
 --enable-suexec \
--suexec-caller=nobody \
--suexec-docroot=/home \
--suexec-logfile=/var/log/httpd/cgi.log \
--suexec-uidmin=500 \
--suexec-gidmin=500 \
--suexec-safepath=/usr/local/bin:/usr/bin:/bin \
--enable-module=so \
--enable-module=access \
--disable-module=auth_db \
--disable-module=digest \
--enable-module=imap \
--enable-module=mime \
--enable-module=setenvif \
--enable-module=usertrack \
--enable-module=auth \
--disable-module=cern_meta \
--disable-module=expires \
--enable-module=log_config \
--disable-module=proxy \
--disable-module=vhost_alias \
--disable-module=auth_anon \
--enable-module=cgi \
--enable-module=headers \
--disable-module=log_referer \
--enable-module=rewrite \
--enable-module=userdir \
--enable-module=asis \
--enable-module=autoindex \
--disable-module=example \
--disable-module=log_agent \
--enable-module=negotiation \
--enable-module=status \
--enable-module=actions \
--disable-module=auth_dbm \
--enable-module=dir \
--enable-module=include \
--disable-module=mime_magic \
--disable-module=unique_id \
--enable-module=alias \
--disable-module=auth_digest \
--enable-module=env \
--disable-module=info \
--disable-module=mmap_static \
--disable-module=speling \
 --enable-module=ssl \
 --activate-module=src/modules/layout/liblayout.a \
 --activate-module=src/modules/ldap/mod_auth_ldap.c \
 --activate-module=src/modules/perl/libperl.a \
 --add-module=mod_frontpage.c --activate-module=src/modules/dav/libdav.a \
 --add-module=/home/local/src/atb/Apachetoolbox-1.5.58/src/mod_gzip.c \
 --activate-module=src/modules/php4/libphp4.a \

Note again that my previous Apache/PHP installation was successfully using all of these options.

I'm not that familiar with using gdb, so I'll explain exactly what I did.  Using this debug version of Apache/PHP, I executed this command:
  gdb /usr/local/apache/bin/httpd

At the (gdb) prompt, I entered this (my Apache configuration doesn't use the default httpd.conf location):

(gdb) run -X -DSSL -f /usr/local/apache/conf/custom/test/httpd.conf

Starting program: /usr/local/apache/bin/httpd -X -DSSL -f /usr/local/apache/conf/custom/test/httpd.conf
Processing config directory: /usr/local/apache/conf/custom/test/virtual
 Processing config file: /usr/local/apache/conf/custom/test/virtual/www.sample.com:80
 
When I hit the phpinfo.php page, this was output in gdb:

Program received signal SIGSEGV, Segmentation fault.
0x81b42a6 in _zend_is_inconsistent (ht=0x63616373, file=0x8364c24 "zend_hash.c", line=681)
    at zend_hash.c:84
84              if (ht->inconsistent==HT_OK) {

I did a backtrace and got this:

(gdb) bt
#0  0x81b42a6 in _zend_is_inconsistent (ht=0x63616373, file=0x8364c24 "zend_hash.c", line=681)
    at zend_hash.c:84
#1  0x81b5e26 in zend_hash_apply (ht=0x63616373, 
    apply_func=0x80c5f78 <php_apache_alter_ini_entries>) at zend_hash.c:681
#2  0x80c6130 in send_php () at md4.c:255
#3  0x80c636f in send_parsed_php () at md4.c:255
#4  0x821bd83 in ap_invoke_handler () at md4.c:255
#5  0x8230b59 in process_request_internal () at md4.c:255
#6  0x8230bbc in ap_process_request () at md4.c:255
#7  0x8227c1e in child_main () at md4.c:255
#8  0x8227dd0 in make_child () at md4.c:255
#9  0x8227f29 in startup_children () at md4.c:255
#10 0x8228586 in standalone_main () at md4.c:255
#11 0x8228d63 in main () at md4.c:255
#12 0x402e59cb in __libc_start_main (main=0x82289fc <main>, argc=5, argv=0xbffffb44, 
    init=0x808f990 <_init>, fini=0x832864c <_fini>, rtld_fini=0x4000aea0 <_dl_fini>, 
    stack_end=0xbffffb3c) at ../sysdeps/generic/libc-start.c:92

I don't know if this is helpful or not.  If you need more details, please let me know what you need and how to get it.

This problem seems to be happening only on any PHP page.  No other document types are causing the problem.  

Normally I would also include APC (alternative cache) and/or Zend Optimizer, but I've left them out for now.

Currently my PHP customers on this server are without reliable PHP service.  Any help or suggestions would be very much appreciated!

Thanks,
Tauren

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-10 07:22 UTC] derick@php.net
Which version of libmcrypt are you using?

Derick
 [2002-07-10 07:42 UTC] tauren at servlets dot net
After looking around on my system, it looks like libmcrypt is fairly old.  It was installed in March 2001.  So I removed it and installed 2.5.1 (it was handy -- I didn't realize 2.5.2 was out when I installed it).  

I also found that libmhash, libfreetype, libt1, and other libraries were fairly old too.  So I cleaned all of them up and installed recent versions.  I then recompiled Apache/PHP.

Unfortunately, the problem still exists with the Segmentation Faults.  However, now I can't get a backtrace in gdb because hitting the phpinfo.php page no longer causes gdb to halt like it was before.  This is even though I'm having just as much if not more trouble bringing up phpinfo.php now that I've reinstalled everything.

Tomorrow I think that I'll reinstall again with a very bare-bones Apache/PHP installation and see if I still have problems.  In the meantime, if anyone has more suggestions, please let me know!

Thanks again,
Tauren
 [2002-07-11 18:24 UTC] tauren at servlets dot net
Any ideas on what is going on here?  All of my hosted sites that use PHP have very poor performance right now because of all the seg faults.  I've tried rolling back to what was installed previously, but I'm still getting the problem.  I've tried compiling Apahce/PHP with no additional options and features, but the problem still persists.  I'm going to try 1.3.26 with an older PHP 4.1 version next.  Some messages on Google seem to indicate that others had success by reverting back.

Any help would be much appreciated!

Tauren
 [2002-07-11 22:01 UTC] sniper@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


 [2002-07-12 03:44 UTC] tauren at servlets dot net
Hi sniper@php.net,

Thanks for the response.  You asked for a backtrace in your message even though I have already submitted several of them.  Are the ones I've submitted not useful?  What more do you suggest I do?

Tauren
 [2002-07-12 03:56 UTC] alan_k@php.net
You mentioned that you do not get segfaults on the phpinfo page anymore (which is where the last gdb back trace indicated you did).

So the last backtrace is not usefull anymore.. - can you run the site again in gdb, apache -X etc. and try and make it segfault.

you may also like to try arvins rpms for redhat 6.2?
http://rpms.arvin.dk/php/rh62/i586/





 [2002-07-17 11:35 UTC] david+php dot net at blue-labs dot org
You'll have to ignore sniper@php.net, he|it|whatever seems to ask for backtraces regardless of their already being posted.

I have a similar problem but I've narrowed it down to sessions.

<?php
   session_start();
?>

This code is sufficient to cause a segfault, I just added my two cents to another bug, I'll fetch that in a moment.  Are you by chance using sessions?
 [2002-07-17 11:38 UTC] david+php dot net at blue-labs dot org
That would be bug 18044 that I posted on.
 [2002-07-17 16:20 UTC] tauren at servlets dot net
I'm going to try using the latest snapshot as suggested in bug #18044.  However, the bug I'm dealing with happens almost immediately after starting apache.  Unfortunately, I have still not been able to get another backtrace.  Things just don't seem to be running the same within gdb.  I can't get any pages to serve when it is running in gdb.

I don't know if the problem is cauase when sessions are used or not.  I am providing Apache as a hosting provider.  It is our customers who's scripts are running on the server.  But I would venture to guess that sessions are most likely in use.

Lastly, it does seem to happen whenever I hit a test page that outputs phpinfo().

Thanks!
Tauren
 [2002-09-29 22:30 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-10-15 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, 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 Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Dec 26 23:01:28 2024 UTC