Bug 454219 - httpd segfaults with sidebar.php from horde
httpd segfaults with sidebar.php from horde
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
9
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
http://bugs.horde.org/ticket/7050
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-06 17:24 EDT by Ola Thoresen
Modified: 2008-07-09 08:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-09 04:15:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
bt full (9.13 MB, text/plain)
2008-07-07 09:04 EDT, Ola Thoresen
no flags Details
print_r of $this (18.13 KB, text/plain)
2008-07-09 03:37 EDT, Ola Thoresen
no flags Details

  None (edit)
Description Ola Thoresen 2008-07-06 17:24:33 EDT
Description of problem:
httpd segafults with latest horde (from cvs, ntot rpm)

Version-Release number of selected component (if applicable):
httpd-2.2.8-3.x86_64
php-5.2.6-2.fc9.x86_64

How reproducible:
Always

Steps to Reproduce:
1. checkout horde from cvs
2. open http://server/horde/

  
Actual results:
apache segfaults in "sidebar.php"
(and sidebar.php is returned as a 0 byte file, so a "save file" dialog appears)

Expected results:
sidebar.php should be parsed and opened in the left frame

Additional info:
The problem seems to be related to this code
  <?php $tree->renderTree() ?>
on line 22 in /usr/share/horde/templates/portal/sidebar.inc


Here are the last lines from a strace of the httpd-process as it segfaults:

lstat("/usr/share/horde/templates/portal/sidebar.inc", {st_mode=S_IFREG|0644,
st_size=1842, ...}) = 0
open("/usr/share/horde/templates/portal/sidebar.inc", O_RDONLY) = 26
fstat(26, {st_mode=S_IFREG|0644, st_size=1842, ...}) = 0
read(26, ""..., 8192)                   = 1842
read(26, "", 8192)                      = 0
read(26, "", 8192)                      = 0
close(26)                               = 0
brk(0x7f9e8d4e4000)                     = 0x7f9e8d4e4000
brk(0x7f9e8d524000)                     = 0x7f9e8d524000
brk(0x7f9e8d564000)                     = 0x7f9e8d564000
brk(0x7f9e8d5a4000)                     = 0x7f9e8d5a4000
brk(0x7f9e8d5e4000)                     = 0x7f9e8d5e4000
brk(0x7f9e8d624000)                     = 0x7f9e8d624000
brk(0x7f9e8d664000)                     = 0x7f9e8d664000
brk(0x7f9e8d6a4000)                     = 0x7f9e8d6a4000
brk(0x7f9e8d6e4000)                     = 0x7f9e8d6e4000
brk(0x7f9e8d724000)                     = 0x7f9e8d724000
brk(0x7f9e8d764000)                     = 0x7f9e8d764000
brk(0x7f9e8d7a4000)                     = 0x7f9e8d7a4000
brk(0x7f9e8d7e4000)                     = 0x7f9e8d7e4000
brk(0x7f9e8d824000)                     = 0x7f9e8d824000
brk(0x7f9e8d864000)                     = 0x7f9e8d864000
brk(0x7f9e8d8a4000)                     = 0x7f9e8d8a4000
brk(0x7f9e8d8e4000)                     = 0x7f9e8d8e4000
brk(0x7f9e8d964000)                     = 0x7f9e8d964000
brk(0x7f9e8d9a4000)                     = 0x7f9e8d9a4000
brk(0x7f9e8d9e4000)                     = 0x7f9e8d9e4000
brk(0x7f9e8da24000)                     = 0x7f9e8da24000
brk(0x7f9e8da64000)                     = 0x7f9e8da64000
brk(0x7f9e8daa4000)                     = 0x7f9e8daa4000
brk(0x7f9e8db24000)                     = 0x7f9e8db24000
brk(0x7f9e8db64000)                     = 0x7f9e8db64000
brk(0x7f9e8dba4000)                     = 0x7f9e8dba4000
brk(0x7f9e8dbe4000)                     = 0x7f9e8dbe4000
brk(0x7f9e8dc24000)                     = 0x7f9e8dc24000
brk(0x7f9e8dc64000)                     = 0x7f9e8dc64000
brk(0x7f9e8dca4000)                     = 0x7f9e8dca4000
brk(0x7f9e8dce4000)                     = 0x7f9e8dce4000
brk(0x7f9e8dd24000)                     = 0x7f9e8dd24000
brk(0x7f9e8dd64000)                     = 0x7f9e8dd64000
mmap(NULL, 790528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f9e8650b000
brk(0x7f9e8dda4000)                     = 0x7f9e8dda4000
brk(0x7f9e8dde4000)                     = 0x7f9e8dde4000
brk(0x7f9e8de24000)                     = 0x7f9e8de24000
brk(0x7f9e8de64000)                     = 0x7f9e8de64000
brk(0x7f9e8dea4000)                     = 0x7f9e8dea4000
brk(0x7f9e8dee4000)                     = 0x7f9e8dee4000
brk(0x7f9e8df24000)                     = 0x7f9e8df24000
brk(0x7f9e8df64000)                     = 0x7f9e8df64000
brk(0x7f9e8dfa4000)                     = 0x7f9e8dfa4000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
Comment 1 Joe Orton 2008-07-07 06:16:03 EDT
Please run:

# echo CoreDumpDirectory /tmp > /etc/httpd/conf.d/coredump.conf
# service httpd restart

reproduce the problem, then do

# gdb /usr/sbin/httpd /tmp/core.xxxxx 
...
(gdb) bt
(gdb) bt.full

and attach the gdb output to this bug report.
Comment 2 Ola Thoresen 2008-07-07 07:05:42 EDT
Hm.
I am not able to make apache create a coredump of the process.
If I do a manual kill -11 of one of the processes a dump is created:

[Mon Jul 07 13:00:08 2008] [notice] child pid 27826 exit signal Segmentation
fault (11), possible coredump in /tmp

However, the segfault that happens on the php-script will not generate one:
[Mon Jul 07 13:00:32 2008] [notice] child pid 27827 exit signal Segmentation
fault (11)

Trying to attach gdb directly to one of the child processes before the segfault
will only make apache not serve any pages with this process.

Any other tips?
Comment 3 Joe Orton 2008-07-07 08:28:02 EDT
Hmmm, weird.  Did you set the process running with "run" after you attached with
gdb and then tried to reproduce?

(it may take N tries for N children running)
Comment 4 Joe Orton 2008-07-07 08:39:17 EDT
that should be "cont" not run, of course.
Comment 5 Ola Thoresen 2008-07-07 09:04:50 EDT
Created attachment 311144 [details]
bt full

Got it now, thanks.
Installed a few more debuginfo-packages as well-

Not sure how much of this you need. I gave up pressing enter after about 10
MB..
Comment 6 Joe Orton 2008-07-08 18:28:37 EDT
Thanks; not much use in the end since it looks like a trashed stack :(

Can you give a precise sequence of instructions which I'd need to follow to be
able to reproduce the bug here (i.e. checkout from horde cvs, configure as
follows, blah)
Comment 7 Joe Orton 2008-07-08 18:30:03 EDT
Actually if you can try just "bt" not "bt full" on that core dump too, that
would be useful; I've seen "bt full" get confused in cases where plain "bt" does
not in the past.
Comment 8 Ola Thoresen 2008-07-09 03:04:46 EDT
Output from "bt"

#0  0x000000004254415f in _zend_hash_quick_add_or_update (ht=0x7f877eaef228,
arKey=0x7f877d29a448 "nodes", nKeyLength=6, h=6953829379134,
pData=0x7fff8229b080, nDataSize=8, pDest=0x7fff8229b0e0, flag=1)
    at /usr/src/debug/php-5.2.6/Zend/zend_hash.c:271
#1  0x00000000425a5e25 in ZEND_RECV_SPEC_HANDLER (execute_data=0x7fff8229b3d0)
at /usr/src/debug/php-5.2.6/Zend/zend_execute.c:160
#2  0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#3  0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229b850) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#4  0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#5  0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229bcd0) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#6  0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#7  0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229c150) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#8  0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#9  0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229c5d0) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#10 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#11 0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229ca50) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#12 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#13 0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229ced0) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#14 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#15 0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229d350) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#16 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#17 0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229d7d0) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#18 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#19 0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229dc50) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#20 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#21 0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229e0d0) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#22 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
#23 0x000000004256f83e in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fff8229e550) at /usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:234
#24 0x000000004255b454 in execute (op_array=0x7f877d330a80) at
/usr/src/debug/php-5.2.6/Zend/zend_vm_execute.h:92
Comment 9 Ola Thoresen 2008-07-09 03:36:21 EDT
This horde-installation might be a bit unregular, as I started with installing
the rpm-packages while the box was still F8.

After a while I needed some new features, and decided to go for the cvs-version
instead.  So I did a cvs checkout in the same dir as the rpm-packages were
installed.
Then I removed the rpms with "--justdb".

However I do not think this is the problem, since the installation worked fine
for several months after that.

Some more info after digging a bit.
If i comment out this code in templates/portal/sidebar.inc the segfault does not
happen:
  <?php $tree->renderTree() ?>

The renderTree() seems to come from the pear-package Horde/Tree.php

That fonctions simply does

    function renderTree($static = false)
    {   
        echo $this->getTree($static);
    }

If i add a 
 print_r($this); 
I can see that this is a javascript-object, so I guess the getTree()-function is
from pear/Horde/Tree/javascript.php

After stepping trough the getTree() function in that file it seems to be
 $this->_buildIndents($this->_root_nodes); 
that is the problem.

_root_nodes contains this:

    [_root_nodes] => Array
        (
            [0] => horde
            [1] => imp
            [2] => dimp
            [3] => organizing
            [4] => myaccount
            [5] => website
            [6] => administration
            [7] => options
            [8] => logout
        )

The function _buildIndents is back in Tree.php, and seems rather simple:

    function _buildIndents($nodes, $indent = 0)
    {   
        foreach ($nodes as $id) {
            $this->_nodes[$id]['indent'] = $indent;
            if (!empty($this->_nodes[$id]['children'])) {
                $this->_buildIndents($this->_nodes[$id]['children'], $indent + 1);
            }
        }
    }

As this is a recursive function, I tried to remove the recursion (the three
lines starting with if (!empty...
That stopped the segfault.

I am attaching a complete print_r() of "$this" for further debugging.



Comment 10 Ola Thoresen 2008-07-09 03:37:24 EDT
Created attachment 311350 [details]
print_r of $this
Comment 11 Joe Orton 2008-07-09 04:15:48 EDT
Ah, actually this looks just like a recursion bug in the application code - PHP
will crash like that in this case.

The:

            [imp] => Array

array has a:

                            [2] => imp

link in its children node, I'd guess that's the same object and the cause of the
recursion.
Comment 12 Ola Thoresen 2008-07-09 08:27:45 EDT
You are right.
This is causing recursion.  I have now followed the codepath and tried to figure
out why this happens, and the code involved does not seem to have changed the
last 6 months.

The code that adds "imp" as a child of "imp" is on line 86 in

http://cvs.horde.org/co.php/imp/lib/Block/tree_folders.php?r=1.71

If I remove that code ($tree->addNode()), the sidebar is displayed.  

But this problem has only existed in a few weeks (I waited a bit before I
reported it because I hoped someone would either discover it and fix it, or it
should be reported by someone else.

So it seems to be that the real problem is somewhere else.

Thanks for the help and feedback so far anyway
Comment 13 Ola Thoresen 2008-07-09 08:39:40 EDT
Reported this to the horde-bugtracker as well.

Note You need to log in before you can comment on or make changes to this bug.