php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #36084 apache2 segfaults on phpinfo()
Submitted: 2006-01-19 13:09 UTC Modified: 2006-03-06 01:00 UTC
Votes:13
Avg. Score:4.2 ± 0.8
Reproduced:11 of 12 (91.7%)
Same Version:10 (90.9%)
Same OS:10 (90.9%)
From: clive at darkarts dot co dot za Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 5.1.2 OS: FreeBSD
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2006-01-19 13:09 UTC] clive at darkarts dot co dot za
Description:
------------
segfault from within apache2, or also if run from the CLI.


Reproduce code:
---------------
<?php
        phpinfo();
?>


Expected result:
----------------
The phpinfo output

Actual result:
--------------
it get's to the 'Apache Environment' section, and within there it gets up to 'SERVER_ADDR' which it displays.

tail snippet of html generated:
<tr><td class="e">SERVER_SOFTWARE </td><td class="v">Apache/2.2.0 (FreeBSD) mod_ssl/2.2.0 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.1.2 </td></tr>
<tr><td class="e">SERVER_NAME </td><td class="v">subzero2 </td></tr>
<tr><td class="e">SERVER_ADDR </td><td class="v">192.168.2.15

It then segfaults.  apache2 log message:
[Thu Jan 19 13:56:48 2006] [notice] child pid 32499 exit signal Abort trap (6)
httpd in free(): error: junk pointer, too high to make sense

If run from the CLI it also seg faults, here is the tail of the command line output of the same:
_ENV["SSH_AUTH_SOCK"] => /tmp/ssh-YxlQmP5Url/agent.32515
_ENV["SHLVL"] => 2
_ENV["PWD"] => /home/users/clive
_ENV["OLDPWD"] => /home/users/clive
_ENV["_"] => /usr/local/bin/php

PHP License
This program is free software; you can redistribute it and/or modify
it under the terms of the PHP License as published by the PHP Group
and included in the distribution in the file:  LICENSE

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If you did not receive a copy of the PHP license, or have any
questions about PHP licensing, please contact license@php.net.
zsh: segmentation fault (core dumped)  php /usr/local/www/apache22/data/index.php




Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-19 13:19 UTC] tony2001@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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

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.


 [2006-01-19 13:49 UTC] clive at darkarts dot co dot za
backtrace is not possible.

when configured with "--enable-debug" it no longer segfaults.  It only segfaults when built without this option
 [2006-01-19 13:56 UTC] sniper@php.net
Does it crash with something more stable than Apache 2.2 ?
Like 2.0 or 1.3.x ?

 [2006-01-19 13:56 UTC] sniper@php.net
And what was the full configure line used to configure PHP?
 [2006-01-19 14:05 UTC] clive at darkarts dot co dot za
after running it enough times i reproduced the segfault with --enable debug, backtrace as follows:

(gdb) bt
#0  0x289a3bf0 in ?? ()
#1  0x2853735f in __cxa_finalize () from /lib/libc.so.6
#2  0x28536f9a in exit () from /lib/libc.so.6
#3  0x081d36c1 in main (argc=2, argv=0xbfbfe8a8) at /usr/ports/lang/php5/work/php-5.1.2/sapi/cli/php_cli.c:1243
 [2006-01-19 14:07 UTC] clive at darkarts dot co dot za
sniper:"Does it crash with something more stable than Apache 2.2 ? Like 2.0 or 1.3.x ?"

yes it crashes the same way from the CLI, without apache at all.
 [2006-01-19 14:17 UTC] clive at darkarts dot co dot za
configure line used:

./configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--enable-spl' '--with-regex=php' '--with-apxs2=/usr/local/sbin/apxs' '--enable-debug' '--prefix=/usr/local' 'i386-portbld-freebsd6.0
 [2006-01-19 14:19 UTC] tony2001@php.net
Please try using this CVS snapshot:

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


 [2006-01-19 14:43 UTC] clive at darkarts dot co dot za
using: http://snaps.php.net/php5.1-latest.tar.gz

./php --version
PHP 5.1.3-dev (cli) (built: Jan 19 2006 15:52:43) (DEBUG)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

and the backtrace:

<snip many lines of the same>
#158 0x6f5f7465 in ?? ()
#159 0x00000000 in ?? ()
#160 0x083d3000 in ?? ()
#161 0x00000000 in ?? ()
#162 0xbfbfe7a0 in ?? ()
#163 0x083d3000 in ?? ()
#164 0xbfbfbba8 in ?? ()
#165 0x08158e06 in _zend_ts_hash_add_or_update (ht=0x6, arKey=0xbfbfb938 "?", '?' <repeats 15 times>, "?3!(", nKeyLength=0, 
    pData=0x28535cb6, nDataSize=1, pDest=0x28234600, flag=-33, __zend_filename=0xffffffff <Address 0xffffffff out of bounds>, 
    __zend_lineno=4294967295) at /usr/ports/lang/php5/work/php5.1-200601191130/Zend/zend_ts_hash.c:102
 [2006-01-19 14:45 UTC] sniper@php.net
Does it crash if you compile against NON-threaded Apache?
Apparently the one you have is threaded. We really don't support that..
 [2006-01-19 14:46 UTC] sniper@php.net
And DO NOT use this: --enable-versioning !!

 [2006-01-19 15:12 UTC] clive at darkarts dot co dot za
Just a side note, before I delve once more into this bug.  All worked fine on my system before I upgraded to 5.1.1, before that, I was using 5.0.5.  This bug was introduced between 5.0.5 and 5.1.1 (apache version unchanged) but at that time i noticed a similar bugreport that seemed to indicate this bug had been found and fixed between 5.1.1 and 5.1.2.  This morning I upgraded from 5.1.1 to 5.1.2 to notice that it was still there.

hmmm, ok I was simply using the FreeBSD defaults as per setup my it's maintainer.  I have never built php from the source myself before this, I normaly rely on the "invisible unsung people behind the scenes" that do all this hard work for me ;)

(still using the latest snap)
the following is (re)built using only:  ./configure --enable-debug.

( there are an incredibly amount of warnings during the compilation of Zend/zend_execute.c )

./php --version
PHP 5.1.3-dev (cli) (built: Jan 19 2006 16:23:21) (DEBUG)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

I then ran the command-line version as such:
./php phpinfo.php

... and voila .. I am unable to get the segfault again.

I would really appreciate feedback on what (in my ./configure line) is causing this, so that I can direct the FreeBSD php maintainer to this bugreport.

Thank you
Clive
 [2006-01-19 15:33 UTC] clive at darkarts dot co dot za
Yes, and I have said many times already that I am using CLI version too *WITHOUT APACHE*,

but, I will give you the info in full again:
ldd ./php                                   
./php:
        libcrypt.so.3 => /lib/libcrypt.so.3 (0x2823a000)
        libm.so.4 => /lib/libm.so.4 (0x28252000)
        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x28268000)
        libz.so.3 => /lib/libz.so.3 (0x28385000)
        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28395000)
        libc.so.6 => /lib/libc.so.6 (0x28484000)


./php phpinfo.php
  <<*snip*>>
report_memleaks => On => On
report_zend_debug => Off => Off
safe_mode => Off => Off
safe_mode_exec_dir => /usr/local/php/bin => /usr/local/php/bin
safe_mode_gid => Off => Off
safe_mode_include_dir => no value => no value
sendmail_from => no value => no value
sendmail_path => /usr/sbin/sendmail -t -i  => /usr/sbin/sendmail -t -i 
serialize_precision => 100 => 100
short_open_tag => On => On
SMTP => localhost => localhost
smtp_port => 25 => 25
sql.safe_modephp in free(): error: junk pointer, too high to make sense
zsh: abort (core dumped)  ./php index.php

gdb ./php php.core
(gdb) bt
#0  0x284c64b3 in kill () from /lib/libc.so.6
#1  0x284bb4f0 in raise () from /lib/libc.so.6
#2  0x28535c5c in abort () from /lib/libc.so.6
#3  0x284dccb3 in _UTF8_init () from /lib/libc.so.6
#4  0xbfbfe91e in ?? ()
#5  0x2853c653 in sys_nsig () from /lib/libc.so.6
#6  0x2853c553 in sys_nsig () from /lib/libc.so.6
#7  0x2853c670 in sys_nsig () from /lib/libc.so.6
#8  0x00000000 in ?? ()
#9  0x285464e4 in ?? () from /lib/libc.so.6
#10 0xbfbfb998 in ?? ()
#11 0x284dcce1 in _UTF8_init () from /lib/libc.so.6
#12 0x285464e4 in ?? () from /lib/libc.so.6
#13 0x0825d928 in _CurrentRuneLocale ()
Previous frame inner to this frame (corrupt stack?)


and just for fun, it's a different segfault this time :(
 [2006-01-19 15:56 UTC] sniper@php.net
It doesn't matter if you run CLI if it's still compiled with ZTS enabled. Which it is if you use the one you build when building the Apache module.

Does this work without crashing:

# rm config.cache ; ./configure --disable-all --disable-cgi && make && sapi/cli/php -r 'phpinfo();'

 [2006-01-19 16:07 UTC] clive at darkarts dot co dot za
Ah, I did not know about ZTS, thank you.

as per your instructions::

on php-5.1.2:
ext/standard/.libs/array.o(.text+0x5ba): In function `zif_count':
/usr/ports/lang/php5/work/php-5.1.2/ext/standard/array.c:326: undefined reference to `spl_ce_Countable'

on php-5.1-200601191130:
runs perfectly, no segfault




(I'm sorry if my next answers come much later, I have to leave now and wont be near a PC again for about 16 hours.  I will answer any questions then as fully as possible.  Thanks )
 [2006-01-19 16:11 UTC] tony2001@php.net
>undefined reference to `spl_ce_Countable'
Yeah, `make clean` is required before `make`.
 [2006-01-19 16:16 UTC] sniper@php.net
Try adding --enable-maintainer-zts to that previous configure line. Does it still crash? What does this output:

# sapi/cli/php -v 

And 'make clean' is _mandatory_ always. (remember to 'rm config.cache' before running the configure line too!)


 [2006-01-20 08:19 UTC] clive at darkarts dot co dot za
commandline as follows was used:
% rm config.cache ; ./configure --disable-all --disable-cgi --enable-maintainer-zts && make clean && make && sapi/cli/php -r 'phpinfo();'

this runs fine, without segfaulting, on both 5.1.2 as well as  the snapshot 5.1-200601191130.

'sapi/cli/php -v' on 5.1.2 gives:
PHP 5.1.2 (cli) (built: Jan 20 2006 09:28:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies


'sapi/cli/php -v' on 5.1.200601191130 gives:
PHP 5.1.3-dev (cli) (built: Jan 20 2006 09:19:48)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
 [2006-01-20 09:22 UTC] sniper@php.net
Now try the same but add --with-apxs2=/usr/local/sbin/apxs to the configure options.
 [2006-01-20 09:47 UTC] clive at darkarts dot co dot za
commandline for both versions (again):

rm config.cache ; ./configure --disable-all --disable-cgi --enable-maintainer-zts --with-apxs2=/usr/local/sbin/apxs && make clean && make && sapi/cli/php -r 'phpinfo();'

no segfaulting, runs fine.
 [2006-01-20 09:51 UTC] sniper@php.net
Then you need to add rest of your options one by one to see which one is causing the problem for you.
 [2006-01-27 01:06 UTC] engin at turk-php dot com
i was having the same issue on same os and same php version
but i didnt try to re-compile with different configure options
coz in the previous php-5.0.5 with ZEND Debugger i faced with similar bug , seg fault, when i removed the Zend Debugger module it was working fine, ( on FreeBSD 4.11 - apache 1.3 )
recently i upgrade my os to FreeBSD-6.0 - apache 2.2 - php 5.1.2
with trial and error method i found imagick and recode modules cause issue 

[Thu Jan 27 02:04:12 2006] [notice] child pid 5968 exit signal Abort
trap (6)
httpd in free(): error: junk pointer, too high to make sense
 [2006-01-28 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, 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".
 [2006-02-03 12:20 UTC] mail at skraemer dot net
This might help you:

I ran into the same problem, and the error dissapeared when i commented out the "ImageMagick"-extension in my "exentsions.ini" (FreeBSD-system).

If you need detailed informations about the cofiguration- / compiling-process, please send me an e-mail.
 [2006-02-05 07:13 UTC] yvovandoorn at comcast dot net
I'm pretty sure this isn't related to Apache2. The reason why is that I am experiencing this problem on two machines, one installed with FreeBSD 5.4 and the other FreeBSD 6.0. The only thing these two have in common is that I installed all my additional applications via the ports.

On both machines the problem goes away the moment I disable the imagemagick extension. Yes both machines are running Apache2, however this problem appeared before php 5.1.2, but sometime a week after the new year.

Since I strongly believe that the imagick extension is the cause of it, I did some checking and found out the port was upgraded for pecl-imagick on 01/05/06 so I'm pretty sure thats where the issue lies. 

I've contacted the maintainer for that port (and strangely he also maintains php5 & php5-extensions).
 [2006-02-05 10:59 UTC] ale at FreeBSD dot org
Have you recompiled pecl-imagick after php update? I have no problems:

%php -v
PHP 5.1.2 (cli) (built: Jan 30 2006 17:07:55)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

%php -i
...
imagick

ImageMagick support => enabled
Magick Backend => ImageMagick
ImageMagick version => 6.2.5
PHP imagick version => 0.9.11
MaxRGB => 65535
Supported image formats => 8BIM
Font Family - Name => AvantGarde - AvantGarde-Book
...
 [2006-02-06 00:26 UTC] yvovandoorn at comcast dot net
I recompiled pecl-imagick on both machines and it still doesn't work. 

I did make deinstall -> make clean -> make install. 

Error message:
php -i
...
imagick

ImageMagick support => enabled
Magick Backend => ImageMagick
ImageMagick version => 6.2.5
PHP imagick version => 0.9.11
MaxRGB => 65535
Supported image formats => 8BIM
php in free(): error: junk pointer, too high to make sense
Abort (core dumped)
 [2006-02-25 10:57 UTC] kama at pvp dot se
This is not really related to imagick. I have got the issue without imagick installed. If I change which extentions I install, phpinfo() will crash in different places.

At first I thought it was a bug in how much data was sent, but after sending 200 tables with 40 rows in each I concluded this was not the problem.

My initial thought was that it has something todo with the plugin api. I have never looked at the source, so this is just a wild guess that it crashes when it query the plugin/extention.

I cvsuped back to 5.0.5 in the portstree and all problems dissappeared. Everything else is the same, I just downgraded php5.
 [2006-02-26 09:08 UTC] tony2001@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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

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.


 [2006-03-06 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, 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: Fri Apr 19 17:01:30 2024 UTC