Do you have a short test script that can reproduce this 
segfault? 
 
J 

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?

It looks like putenv() is the last thing called from PHP 
land before the crash, so that's a start. 
 
J 

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.

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?

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;
}

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.

Not bug in PHP -> bogus.

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.

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;
                }
        }

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.

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.

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.

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.

I've run the suspect script twice without a seg fault.  It looks like you may have fixed it as of php4-STABLE-200304151330.

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.