php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23040 Periodic Segmentation Faults
Submitted: 2003-04-03 15:22 UTC Modified: 2003-04-15 13:13 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: tim at danan dot com Assigned:
Status: Closed Package: Apache related
PHP Version: 4.3.1 OS: Redhat 8
Private report: No CVE-ID: None
 [2003-04-03 15:22 UTC] tim at danan dot com
I have a page that is generating repeated segmentation faults on a Redhat 8 system running Apache 1.3.27 and PHP 4.3.1.  It is part of a forum system (FudForum) that, unforunately, I didn't write.  MySQL and sessions are both involved. The faults are not occurring on every use, but seem to occur about once an hour.  Once a seg fault appears I tend to see 4-5 of them in succession, then they disappear again for an hour or so. 

[Thu Apr  3 14:18:51 2003] [notice] child pid 8668 exit signal Segmentation fault (11)

I was able to generate a backtrace by running httpd -X in gdb.

(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x40262195 in calloc () from /lib/libc.so.6
(gdb) bt
#0  0x40262195 in calloc () from /lib/libc.so.6
#1  0x40260f60 in realloc () from /lib/libc.so.6
#2  0x402176cf in putenv () from /lib/libc.so.6
#3  0x402175f8 in putenv () from /lib/libc.so.6
#4  0x404e6b41 in zif_putenv (ht=1, return_value=0x86fb92c, this_ptr=0x0, return_value_used=0)
    at /usr/local/src/php-4.3.1/ext/standard/basic_functions.c:1353
#5  0x405ab626 in execute (op_array=0x86ec4f0) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1596
#6  0x405ab859 in execute (op_array=0x86ea418) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1640
#7  0x405ab859 in execute (op_array=0x86459ac) at /usr/local/src/php-4.3.1/Zend/zend_execute.c:1640
#8  0x4059a321 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-4.3.1/Zend/zend.c:864
#9  0x40564f6b in php_execute_script (primary_file=0xbffff390) at /usr/local/src/php-4.3.1/main/main.c:1573
#10 0x405b0546 in apache_php_module_main (r=0x841801c, display_source_mode=0)
    at /usr/local/src/php-4.3.1/sapi/apache/sapi_apache.c:55
#11 0x405b13e6 in send_php (r=0x841801c, display_source_mode=0, filename=0x8419dfc "/var/www/html/forum/index.php")
    at /usr/local/src/php-4.3.1/sapi/apache/mod_php4.c:556
#12 0x405b145f in send_parsed_php (r=0x841801c) at /usr/local/src/php-4.3.1/sapi/apache/mod_php4.c:571
#13 0x080cd6f4 in ap_invoke_handler ()
#14 0x080e209a in process_request_internal ()
#15 0x080e20fa in ap_process_request ()
#16 0x080d92e2 in child_main ()
#17 0x080d94a8 in make_child ()
#18 0x080d960f in startup_children ()
#19 0x080d9c3c in standalone_main ()
#20 0x080da474 in main ()
#21 0x40202907 in __libc_start_main () from /lib/libc.so.6


GCC Version: gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

My php config is VERY simple:

./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--with-mysql \
--with-pgsql \
--with-pspell \
--enable-debug


I'm sure there is a great deal of additional information I can provide, and I will do so quite willingly.  My apologies if I've overlooked anything in this report.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-04-03 15:51 UTC] jay@php.net
Do you have a short test script that can reproduce this 
segfault? 
 
J 
 [2003-04-03 16:36 UTC] tim at danan dot com
I've not been able to narrow it down to anything that specific yet.  I've only just narrowed it down to this page in the past day or so.  Unfortunately, the page almost 700 lines long, so I wouldn't call it "short".

I'll continue to try to narrow it down to see if I can isolate a function, but it may not be easy since the page tends to load fine 50-60 times in a row, then blow up.   There's probably something unique going on in the crash instances, but I've not located it yet.

If you'd like the long script I'll be happy to provide it.

I'm not an expert at reading dumps by any means.  Does anything jump out at you?  Are there any hints of some place I might be able to look to help narrow things down?
 [2003-04-03 16:49 UTC] jay@php.net
It looks like putenv() is the last thing called from PHP 
land before the crash, so that's a start. 
 
J 
 [2003-04-03 19:38 UTC] sniper@php.net
Please try using this CVS snapshot:

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

There have been couple of dozen fixes that might have
also fixed this. So please give the snapshot a go.

 [2003-04-04 08:13 UTC] tim at danan dot com
I tried the cvs snapshot and I'm still seeing the seg faults.  Is it possible that Apache is the problem here and not PHP?  In other words, is the putenv setting with an enviroment variable for PHP or all of httpd?
 [2003-04-04 08:38 UTC] tim at danan dot com
AHA!  I just checked the script (and all of it's includes).  There is only one putenv call in the entire forum system.  Perhaps these code snippets can provide some insight (I'm going to see if I can crash the server with a short script containing these functions).

//included from a conf file
$SERVER_TZ              = "America/New_York";

// the potential offending code
function set_tz($timezone)
{
        if( $timezone ) @putenv("TZ=".$timezone);
}

// one of the fields in users is time_zone.  All users are currently set to "America/New_York"
function get_user_by_id($id)
{
	 qobj("SELECT * FROM fud2_users WHERE id=".$id, $this);
	 if( empty($this->id) ) return;
	 return $this->id;
}

// within this init function the set_tz function is called
function init_user()
{
        $s = new fud_session;

        $u = new fud_user;

        $s->cookie_get_session();
        if ( $s->user_id && $s->user_id<2000000000 ) {
                if ( !$u->get_user_by_id($s->user_id) ) {
                        $u=NULL;
                        $s->delete_session();
                }
                /* else NOP */
        }
        else $u = NULL;

        if ( empty($u) && empty($s->id) ) $s->save_session();

        $rv[0] = $s;

        if( !empty($u) ) {
                set_tz($u->time_zone);

                define('d_thread_view', (($GLOBALS['TREE_THREADS_ENABLE']=='N'||$u->default_view=='msg'||$u->default_view=='tree_msg')?'msg':'tree'));
                define('t_thread_view', (($GLOBALS['TREE_THREADS_ENABLE']=='N'||$u->default_view=='msg'||$u->default_view=='msg_tree')?'thread':'threadt'));

                q("UPDATE fud2_users SET last_visit=".__request_timestamp__." WHERE id=".$u->id);
                $rv[1] = $u;
        }else {
                set_tz($GLOBALS["SERVER_TZ"]);

                define('d_thread_view', (($GLOBALS['TREE_THREADS_ENABLE']=='N'||$GLOBALS['DEFAULT_THREAD_VIEW']=='msg'||$GLOBALS['DEFAULT_THREAD_VIEW']=='tree_msg')?'msg':'tree'));
                define('t_thread_view', (($GLOBALS['TREE_THREADS_ENABLE']=='N'||$GLOBALS['DEFAULT_THREAD_VIEW']=='msg'||$GLOBALS['DEFAULT_THREAD_VIEW']=='msg_tree')?'thread':'threadt'));

                $rv[1] = NULL;
                if( !empty($GLOBALS["rid"]) && empty($GLOBALS["HTTP_COOKIE_VARS"]["frm_referer_id"]) ) set_referer_cookie($GLOBALS["rid"]);
        }

        define('s', $s->ses_id);
        define('_rsid', 'rid='.$u->id.'&amp;S='.s);
        define('_rsidl', 'rid='.$u->id.'&S='.s);
        define('_hs', '<input type="hidden" name="S" value="'.s.'">');
        define('_uid', (($u->email_conf == 'Y')?$u->id:0));

        return $rv;
}
 [2003-04-05 07:29 UTC] tim at danan dot com
I'm marking this one as closed.  It appears that the problem was in apache, not php.  It looks like a couple of recent glibc rpm updates were the source of the problem.  After rebuilding apache and php I haven't seen a seg faults in over 16 hours.  Perviously I was seeing 5-10 per hour.

Thank you to those of you who took the time to help me with this problem.
 [2003-04-05 11:28 UTC] sniper@php.net
Not bug in PHP -> bogus.


 [2003-04-11 14:28 UTC] philip@php.net
After some discussion with Tim it appears this bug is still open.  His original conclusion changed one hour later but this report remained untouched/closed.  In summary: The origin of this bug has not been confirmed.
 [2003-04-11 14:45 UTC] tim at danan dot com
With a little prodding from Philip, here's what I posted on the FUDForum site, seeking some input after the problem came back in a different place.  It's now definitely reproducable.

=====
I've been struggling with a similar seg fault issue for the past two weeks. I've been bouncing a bug report around with the PHP team, but we haven't been able to narrow anything down.  This morning I thought I had fixed the problem after a recompile of Apache and PHP. I went about 15 hours without a seg fault. That all changed once I ran a compact messages on FudForum.

Previously my seg faults were semi-random. Now I can seg fault PHP on demand. I've been testing with a hacked up version of the compact page (adm/compact.php) - I'm slowly adding the code back in until I produce errors. The seg fault is occuring after the post and appears to be somewhere around the time of the db_lock (line 110).

Is there anything you can do to help me out? I wasn't able to give the PHP guys enough detail about a specific function/script (the problem seemed to be happening on the index page previously) to get a good bug report for them. This problem is definitely reproducible (every time I press submit), so if I/we can narrow it down to a function perhaps we can either (1) find the problem in PHP, or (2) find the problem in FUDForum.


Config information and backtrace follow:

RedHat 8
Apache 1.3.27
PHP 4.3.2-RC (Friday's CVS, installed per recommendation of PHP team)
FUDForum version is 2.3.9-RC1
MySQL version (from RPM) is mysql-server-3.23.54a-4

Apache and PHP are compiled by me with very few options turned on. PHP is configured as follows:

./configure \
--with-apxs=/usr/local/apache/bin/apxs \
--with-mysql \
--with-pgsql \
--with-pspell \
--enable-debug


BACKTRACE

Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x402520b1 in setvbuf () from /lib/libc.so.6
(gdb) bt
#0 0x402520b1 in setvbuf () from /lib/libc.so.6
#1 0x4053f74a in php_stdiop_set_option (stream=0x84b6624, option=3, value=2, ptrparam=0xbfff9130)
at /usr/local/src/php4-STABLE-200304041230/main/streams.c:1636
#2 0x4053eaea in _php_stream_set_option (stream=0x84b6624, option=3, value=2, ptrparam=0xbfff9130)
at /usr/local/src/php4-STABLE-200304041230/main/streams.c:1002
#3 0x404e3e30 in zif_stream_set_write_buffer (ht=2, return_value=0x84b5e6c, this_ptr=0x0, return_value_used=0)
at /usr/local/src/php4-STABLE-200304041230/ext/standard/file.c:1607
#4 0x405675ea in execute (op_array=0x8430a54)
at /usr/local/src/php4-STABLE-200304041230/Zend/zend_execute.c:1606
#5 0x4055ae19 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/src/php4-STABLE-200304041230/Zend/zend.c:864
#6 0x40535de7 in php_execute_script (primary_file=0xbfffebb0)
at /usr/local/src/php4-STABLE-200304041230/main/main.c:1653
#7 0x4056b172 in apache_php_module_main (r=0x840f47c, display_source_mode=0)
at /usr/local/src/php4-STABLE-200304041230/sapi/apache/sapi_apache.c:55
#8 0x4056bc05 in send_php (r=0x840f47c, display_source_mode=0, filename=0x0)
at /usr/local/src/php4-STABLE-200304041230/sapi/apache/mod_php4.c:617
#9 0x4056bd9a in send_parsed_php (r=0x840f47c)
at /usr/local/src/php4-STABLE-200304041230/sapi/apache/mod_php4.c:632
#10 0x080c5c04 in ap_invoke_handler ()
#11 0x080da5aa in process_request_internal ()
#12 0x080da60a in ap_process_request ()
#13 0x080d17f2 in child_main ()
#14 0x080d19b8 in make_child ()
#15 0x080d1b1f in startup_children ()
#16 0x080d214c in standalone_main ()
#17 0x080d2984 in main ()
#18 0x40202907 in __libc_start_main () from /lib/libc.so.6

=====

Here's the code around the function in question.  Sorry I can't make it more clear, but it's within an admin function in someone else's code.:

        echo "<br>Please wait while forum is being compacted.<br>This may take a while depending on the size of your forum.<br>\n";
        flush();

        define('__file_perms__', (($GLOBALS['FILE_LOCK']=='Y')?0600:0644));

        /* Normal Messages */
        echo "Compacting normal messages...<br>\n";
        flush();
        $stm = time();
        db_lock($GLOBALS['DBHOST_TBL_PREFIX'].'msg+, '.$GLOBALS['DBHOST_TBL_PREFIX'].'thread+, '.$GLOBALS['DBHOST_TBL_PREFIX'].'forum+, '.$GLOBALS['DBHOST_TBL_PREFIX'].'replace+');

        $files = array();
        $r = q("SELECT ".$GLOBALS['DBHOST_TBL_PREFIX']."msg.id,foff,length,file_id,message_threshold
                        FROM ".$GLOBALS['DBHOST_TBL_PREFIX']."msg
                        INNER JOIN ".$GLOBALS['DBHOST_TBL_PREFIX']."thread
                                ON ".$GLOBALS['DBHOST_TBL_PREFIX']."msg.thread_id=".$GLOBALS['DBHOST_TBL_PREFIX']."thread.id
                        INNER JOIN ".$GLOBALS['DBHOST_TBL_PREFIX']."forum
                                ON ".$GLOBALS['DBHOST_TBL_PREFIX']."thread.forum_id=".$GLOBALS['DBHOST_TBL_PREFIX']."forum.id
                        ORDER BY thread_id, id ASC");


        $rpl_arr = make_replace_array();
        $rvs_rpl_arr = make_reverse_replace_array();

        $do_replace = $do_rvs_replace = 0;

        if( is_array($rpl_arr) && count($rpl_arr['pattern']) && count($rpl_arr['replace']) )
                $do_replace = 1;
        if( is_array($rvs_rpl_arr) && count($rvs_rpl_arr['pattern']) && count($rvs_rpl_arr['replace']) )
                $do_rvs_replace = 1;

        if( db_count($r) ) {
                $ten_percent = round(db_count($r)/10);
                $i=0;

                while( $obj = db_rowobj($r) ) {
                        if( empty($files[$obj->file_id]) ) $files[$obj->file_id]=1;

                        $msg = read_msg_body($obj->foff, $obj->length, $obj->file_id);

                        if( $do_rvs_replace ) $msg = preg_replace($rvs_rpl_arr['pattern'], $rvs_rpl_arr['replace'], $msg);
                        if( $do_replace ) $msg = preg_replace($rpl_arr['pattern'], $rpl_arr['replace'], $msg);

                        $file_id = write_body_c($msg, $len, $off);

                        if ( $obj->message_threshold && $obj->message_threshold < strlen($msg) ) {
                                $thres_body = trim_html($msg, $obj->message_threshold);
                                $file_id_preview = write_body_c($thres_body, $length_preview, $offset_preview);
                        }

                        q("UPDATE ".$GLOBALS['DBHOST_TBL_PREFIX']."msg SET
                                foff=".$off.",
                                length=".$len.",
                                file_id=".$file_id.",
                                file_id_preview=".intzero($file_id_preview).",
                                offset_preview=".intzero($offset_preview).",
                                length_preview=".intzero($length_preview)."
                        WHERE id=".$obj->id);

                        if( $ten_percent && !($i%$ten_percent) && $i ) {
                                echo ($i/$ten_percent*10)."% done<br>\n";
                                flush();
                        }
                        $i++;
                }
        }
        else { /* there are no messages in db, make sure that msg files are blank */
                $i=0;
                while (++$i<100) {
                        if( @file_exists($GLOBALS['MSG_STORE_DIR'].'msg_'.$i) )
                                @unlink($GLOBALS['MSG_STORE_DIR'].'msg_'.$i);
                        else
                                break;
                }
        }
 [2003-04-13 10:33 UTC] tim at danan dot com
I thought of one more piece of information that might be helpful.  I'm not on an Intel chipset.  My box is running an Athlon processor, for what it's worth.
 [2003-04-14 20:35 UTC] iliaa@php.net
Please try using this CVS snapshot:

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

I believe that my recent patch for bug #23201 should resolve this bug as well.
 [2003-04-14 20:55 UTC] tim at danan dot com
I rebuilt PHP with the snapshot version you specified and re-ran the problematic script.

[Mon Apr 14 21:52:28 2003] [notice] child pid 32619 exit signal Segmentation fault (11)

Thank you for looking ito this issue.  Please let me know if I can provide any other information for you.
 [2003-04-14 21:05 UTC] iliaa@php.net
The snapshots for *nix are built every 2 hours or so, therefor the fix won't be in a snapshot until about 1 1/2 hours from now.
Please try it then.
 [2003-04-15 13:10 UTC] tim at danan dot com
I've run the suspect script twice without a seg fault.  It looks like you may have fixed it as of php4-STABLE-200304151330.
 [2003-04-15 13:13 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sat Jun 25 20:05:44 2022 UTC