|  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
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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: tauren at servlets dot net
New email:
PHP Version: OS:


 [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:

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:

./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/
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!



Add a Patch

Pull Requests

Add a Pull Request


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

 [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,
 [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!

 [2002-07-11 22:01 UTC]
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

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

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?

 [2002-07-12 03:56 UTC]
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?

 [2002-07-17 11:35 UTC] david+php dot net at blue-labs dot org
You'll have to ignore, 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.


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().

 [2002-09-29 22:30 UTC]
Please try using this CVS snapshot:
For Windows:

 [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: Sun Feb 25 03:01:28 2024 UTC