#23040 [Opn->Fbk]: Periodic Segmentation Faults

ID: 23040 Updated by: iliaa@php.net Reported By: tim at danan dot com -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Redhat 8 PHP Version: 4.3.1 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2003-04-13 10:33:18] 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-11 14:45:04] 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-11 14:28:02] 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-05 11:28:09] sniper@php.net Not bug in PHP -> bogus. ------------------------------------------------------------------------ [2003-04-05 07:29:45] 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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/23040 -- Edit this bug report at http://bugs.php.net/?id=23040&edit=1