php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56235 Seg fault with php 4.3.9 / Apache 1.3.31
Submitted: 2004-11-22 14:04 UTC Modified: 2012-07-08 03:34 UTC
From: gsstark at mit dot edu Assigned: chx (profile)
Status: Closed Package: APC (PECL)
PHP Version: Irrelevant OS: Debian i386
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.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: gsstark at mit dot edu
New email:
PHP Version: OS:

 

 [2004-11-22 14:04 UTC] gsstark at mit dot edu
Description:
------------
APC would work for the first couple pages then seg fault 
immediately  
without returning any data to the browser:  
  

Actual result:
--------------
 
[Mon Nov 22 11:40:50 2004] [notice] Apache/1.3.31 (Debian 
GNU/Linux) PHP/4.3.9-1 mod_perl/1.29 configured -- resuming 
normal operations 
[Mon Nov 22 11:40:50 2004] [notice] Accept mutex: sysvsem 
(Default: sysvsem) 
[Mon Nov 22 11:41:04 2004] [notice] child pid 8860 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:41:06 2004] [notice] child pid 8888 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:41:08 2004] [notice] child pid 8889 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:41:10 2004] [notice] child pid 8861 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:41:41 2004] [notice] child pid 8892 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:41:41 2004] [notice] child pid 8893 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:42:00 2004] [notice] child pid 8894 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:42:00 2004] [notice] child pid 8895 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:42:06 2004] [notice] child pid 8859 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:42:06 2004] [notice] child pid 8857 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:42:08 2004] [notice] child pid 8887 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:42:39 2004] [notice] child pid 8858 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:48:38 2004] [notice] child pid 8928 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:48:38 2004] [notice] child pid 8932 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:48:52 2004] [notice] child pid 8934 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:48:52 2004] [notice] child pid 8935 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:48:55 2004] [notice] child pid 8937 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:48:55 2004] [notice] child pid 8938 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:50:24 2004] [notice] child pid 8939 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:50:24 2004] [notice] child pid 8940 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:51:16 2004] [notice] child pid 9055 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:51:17 2004] [notice] child pid 9060 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:53:17 2004] [notice] child pid 9107 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:53:17 2004] [notice] child pid 9110 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:53:23 2004] [notice] child pid 9061 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:53:23 2004] [notice] child pid 9062 exit signal 
Segmentation fault (11) 
[Mon Nov 22 11:56:11 2004] [notice] caught SIGTERM, shutting 
down 
 
 
I couldn't get a backtrace out of apache, but strace was able to 
catch it sometimes: 
 
[pid  9055] open("/usr/lib/locale/locale-archive", O_RDONLY|
O_LARGEFILE) = 7 
[pid  9055] fstat64(7, {st_mode=S_IFREG|0644, 
st_size=4216816, ...}) = 0 
[pid  9055] mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 7, 
0) = 0x42a30000 
[pid  9055] close(7)                    = 0 
[pid  9055] --- SIGSEGV (Segmentation fault) @ 0 (0) --- 
 
Which doesn't really enlighten me too much.  

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-11-22 14:07 UTC] rasmus@php.net
gdb /usr/sbin/apache
run -X

Then hit the server until you get the segfault and then type bt in gdb and send us that.
 [2004-11-22 14:17 UTC] gsstark at mit dot edu
yeah, i was already working on that 
 
 
(gdb) bt 
#0  0x405d80d8 in zend_hash_get_current_data_ex () 
   from /usr/lib/apache/1.3/libphp4.so 
#1  0x405ca094 in zval_update_constant () 
from /usr/lib/apache/1.3/libphp4.so 
#2  0x405d75c0 in zend_hash_apply_with_argument () 
   from /usr/lib/apache/1.3/libphp4.so 
#3  0x405ca296 in zval_update_constant () 
from /usr/lib/apache/1.3/libphp4.so 
#4  0x405d75c0 in zend_hash_apply_with_argument () 
   from /usr/lib/apache/1.3/libphp4.so 
#5  0x405d3701 in _object_and_properties_init () 
   from /usr/lib/apache/1.3/libphp4.so 
#6  0x405d373c in _object_init_ex () 
from /usr/lib/apache/1.3/libphp4.so 
#7  0x405e1c1f in execute () 
from /usr/lib/apache/1.3/libphp4.so 
#8  0x407f3186 in my_execute (op_array=0x9530c7c) 
    at /usr/local/src/APC-2.0.4/apc_main.c:199 
#9  0x405d2751 in zend_execute_scripts () 
from /usr/lib/apache/1.3/libphp4.so 
#10 0x405a571f in php_execute_script () 
from /usr/lib/apache/1.3/libphp4.so 
#11 0x405e520e in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#12 0x405e5dcc in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#13 0x405e5f91 in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#14 0x080552d3 in ap_invoke_handler () 
---Type <return> to continue, or q <return> to quit--- 
#15 0x08068325 in ap_some_auth_required () 
#16 0x080684d4 in ap_process_request () 
#17 0x08060ab2 in ap_child_terminate ()
 [2004-11-22 14:29 UTC] gsstark at mit dot edu
#0  0x405d80d8 in zend_hash_get_current_data_ex () 
   from /usr/lib/apache/1.3/libphp4.so 
#1  0x405ca094 in zval_update_constant () 
from /usr/lib/apache/1.3/libphp4.so 
#2  0x405d75c0 in zend_hash_apply_with_argument () 
   from /usr/lib/apache/1.3/libphp4.so 
#3  0x405ca296 in zval_update_constant () 
from /usr/lib/apache/1.3/libphp4.so 
#4  0x405d75c0 in zend_hash_apply_with_argument () 
   from /usr/lib/apache/1.3/libphp4.so 
#5  0x405d3701 in _object_and_properties_init () 
   from /usr/lib/apache/1.3/libphp4.so 
#6  0x405d373c in _object_init_ex () 
from /usr/lib/apache/1.3/libphp4.so 
#7  0x405e1c1f in execute () 
from /usr/lib/apache/1.3/libphp4.so 
#8  0x407f3186 in my_execute (op_array=0x962af34) 
    at /usr/local/src/APC-2.0.4/apc_main.c:199 
#9  0x405d2751 in zend_execute_scripts () 
from /usr/lib/apache/1.3/libphp4.so 
#10 0x405a571f in php_execute_script () 
from /usr/lib/apache/1.3/libphp4.so 
#11 0x405e520e in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#12 0x405e5dcc in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#13 0x405e5f91 in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#14 0x080552d3 in ap_invoke_handler () 
---Type <return> to continue, or q <return> to quit--- 
#15 0x08068325 in ap_some_auth_required () 
#16 0x080684d4 in ap_process_request () 
#17 0x08060ab2 in ap_child_terminate ()
 [2004-11-22 14:30 UTC] gsstark at mit dot edu
(gdb) bt 
#0  0x405d80d8 in zend_hash_get_current_data_ex () 
   from /usr/lib/apache/1.3/libphp4.so 
#1  0x405ca094 in zval_update_constant () 
from /usr/lib/apache/1.3/libphp4.so 
#2  0x405d75c0 in zend_hash_apply_with_argument () 
   from /usr/lib/apache/1.3/libphp4.so 
#3  0x405ca296 in zval_update_constant () 
from /usr/lib/apache/1.3/libphp4.so 
#4  0x405d75c0 in zend_hash_apply_with_argument () 
   from /usr/lib/apache/1.3/libphp4.so 
#5  0x405d3701 in _object_and_properties_init () 
   from /usr/lib/apache/1.3/libphp4.so 
#6  0x405d373c in _object_init_ex () 
from /usr/lib/apache/1.3/libphp4.so 
#7  0x405e1c1f in execute () 
from /usr/lib/apache/1.3/libphp4.so 
#8  0x407f3186 in my_execute (op_array=0x9530c7c) 
    at /usr/local/src/APC-2.0.4/apc_main.c:199 
#9  0x405d2751 in zend_execute_scripts () 
from /usr/lib/apache/1.3/libphp4.so 
#10 0x405a571f in php_execute_script () 
from /usr/lib/apache/1.3/libphp4.so 
#11 0x405e520e in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#12 0x405e5dcc in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#13 0x405e5f91 in apache_php_module_main () 
   from /usr/lib/apache/1.3/libphp4.so 
#14 0x080552d3 in ap_invoke_handler ()
 [2004-11-22 14:33 UTC] gsstark at mit dot edu
[Incidentally, this bug report system is almost as annoying 
as bugzilla. The remember your password thing doesn't work 
I've had to enter a password every time. And if I just use 
the plain add info form without a password it redirects me 
here and loses all the info I pasted.] 
 
A couple times I've had an interesting non-seg fault 
symptom. It corrupted the string stored in a PHP array. 
Both times it was the last few characters that were dropped 
and replaced by a single character. Once it changed "asc" 
to "as0" and once it changed "desc" to "dP". 
 
It looks to me like a buffer overflow in the block 
allocated to store a hash entry.
 [2004-11-22 14:41 UTC] rasmus@php.net
Actually, it didn't lose your info.  Your backtrace is here 3 times now.

And the PHP code that goes along with that backtrace?  It looks like you have a constant as an object property or something along those lines?
 [2004-11-22 14:48 UTC] gsstark at mit dot edu
Actually those are three different backtraces. I think. 
Unless I got confused in retrying and ended up pasting the 
wrong ones in. 
 
I have no idea which PHP code corresponds to the 
backtraces. The page I was fetching was a smarty templated 
page with multiple objects involved and multiple included 
templates involved. 
 
The code that corresponds to the failures where the 
corrupted data is visible is code of the form: 
 
Class Foo extends Bar 
{ 
     var $sort_expressions = array( 
                              name => array('brand_xform 
asc', 'brand_xform desc'), 
                              num_ads => array('num_ads 
desc, brand_xform asc', 'num_ads asc, brand_xform desc', 
backwards => 1), 
                              num_ads_recent => 
array('num_ads desc, last_updated desc', 'num_ads asc, 
last_updated asc', backwards => 1), 
                              ); 
 
 
which is later used in a function with code of the form: 
 
    function get_rows($params = array()) 
    { 
        global $db; 
        $sort   = array_key_exists('sort',   $params) ? 
$params[sort]    : $this->sort; 
        $sort_dir = array_key_exists('sort_dir', $params) ? 
$params[sort_dir] : $this->sort_dir; 
 
        $sort_clause = $this->sort_expressions[$sort]
[$sort_dir]; 
... 
        $rows = $db->getall(" 
            SELECT * FROM ... ORDER BY $sort_clause
 [2004-11-22 14:50 UTC] gsstark at mit dot edu
Ugh, the web form widget word wrapped that. Is there an 
email interface I can submit info to to avoid that problem?
 [2004-11-22 15:00 UTC] gsstark at mit dot edu
I sent additional info to rasmus@php.net
 [2004-11-26 03:54 UTC] gsstark at mit dot edu
Any news?
 [2004-11-26 04:27 UTC] rasmus@php.net
I never got anything from you.  You probably didn't validate that message.  But, unless you come up with a 5-10 line reproducing script I am not going to have time to look at it.  I can't spend days trying to reproduce something like this.
 [2004-11-26 05:22 UTC] gsstark at mit dot edu
> I never got anything from you.  You probably didn't  
> validate that message.   
 
If you have some kind of validation based spam filter then 
no I wouldn't have. My spam filters routinely eat such 
things but when they get through I don't respond on 
principle. 
 
In any case it was just the same data I already sent but 
without the line wrapping damage your web form did. 
 
> But, unless you come up with a 5-10 line reproducing 
> script I am not going to have time to look at it.  I  
> can't spend days trying to reproduce something like this. 
 
Uh, well, if I could do that I would have found the bug 
already. It's not like this is a hard problem to reproduce, 
It happened on the first page I tried to run, and every 
page I've tried since. And I'm not the first to report it. 
 
Frankly that backtrace is more data than most bug reports 
come with. The normal course of action would be to take 
this as a sign that there should be a whackload more 
assertions in the code so this type of corruption produces 
a more useful backtrace. 
 
Look, it's your software. I'm just trying to help you 
improve it by reporting bugs. If you're not interested in 
them then well, that's up to you.  
 
I guess I'll stick with mmcache which at least runs, though 
as far as I can tell it's utterly unmaintained.
 [2004-11-26 12:48 UTC] rasmus@php.net
More info that most bug reports?  You haven't even said which version of APC you are using.  And have you tried the current code to see if the bug is even still there?
 [2004-11-26 13:44 UTC] gsstark at mit dot edu
> You haven't even said which version of 
> APC you are using.   
 
Well the tarball is named APC-2.0.4. However the 
apc_version() function says 2.0.3.  
 
> And have you tried the current code to see if the 
> bug is even still there? 
 
I don't see any releases since I reported the bug last 
week. http://pecl.php.net/package-info.php?package=APC 
doesn't show any hint of where to find the CVS tree. 
 
In any case I doubt the bug magically disappeared. If you 
haven't fixed a a hash corruption bug recently I expect it 
would still be there.
 [2004-11-26 13:59 UTC] gschlossnagle@php.net
Greg (you're Greg Stark, formerly of Ideas & Assoc., 
right?).

APC is run all over Yahoo!, as well as several of the 
other top 10 trafficed PHP sites in the world, so its 
not as easy to duplicate as you make it sound. Can you 
put together some sort of reproducing case, please?  
Regardless of how bugs are submitted in other projects, 
that usually considered a minimal standard here.

Thanks,

George

(p.s. Theo says hi) 
 [2004-11-27 04:20 UTC] rasmus@php.net
If you go to http://cvs.php.net you will see a link to the anonymous CVS instructions.  Just check out pecl/apc from the repository and you will have the current code.

And the bug could actually have been fixed.  It's been quite a while since the last release and a lot of the memory handling has been cleaned up since then.
 [2012-07-08 03:34 UTC] chx@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: chx
 [2012-07-08 03:34 UTC] chx@php.net
APC bug queue cleanup.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sat Sep 21 09:01:27 2019 UTC