From owner-freebsd-questions@FreeBSD.ORG Mon Feb 5 15:07:29 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A5D716A400 for ; Mon, 5 Feb 2007 15:07:29 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) by mx1.freebsd.org (Postfix) with ESMTP id 15B2013C428 for ; Mon, 5 Feb 2007 15:07:29 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9] (may be forged)) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l15F7SPh003636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Feb 2007 07:07:28 -0800 X-Auth-Received: from [192.168.10.41] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l15F7Qs4017967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Feb 2007 07:07:27 -0800 Message-ID: <45C7482D.2060103@u.washington.edu> Date: Mon, 05 Feb 2007 07:07:25 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <20070203204156.A4743@badger.tltodd.com> <45C5A93A.8010501@infracaninophile.co.uk> <20070205055425.A68136@badger.tltodd.com> In-Reply-To: <20070205055425.A68136@badger.tltodd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.5.65433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_NAME_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0, __USER_AGENT 0' Subject: Re: phpMyAdmin httpd segmentation fault X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2007 15:07:29 -0000 Terry Todd wrote: > On Sun, Feb 04, 2007 at 09:36:58AM +0000, Matthew Seaman wrote: >> Terry Todd wrote: >>> I installed FreeBSD 6.2-RELEASE, php-5.1.6_3, php5-extensions-1.0, >>> mysql-5.0.27 and apache_1.3.37_1. >>> >>> php -i now works Ok after I moved recode.so to the top of the list >>> of extensions in extensions.ini. It took a while to figure that >>> one out. Before that php -i would seg fault and core dump. It >>> took some google searching and using gdb on the core file to fix >>> it. >>> >>> A test web page for phpinfo works fine too. Mysql works OK from >>> the command line. >>> >>> However I can't get phpMyAdmin to work. It seg faults in reading >>> /usr/local/www/phpMyAdmin/libraries/url_generating.lib.php >>> There is no core dump produced. >> Hmmm... very strange. We have just built a RELENG_6_2 server with >> apache13-ssl, php5 and phpMyAdmin and no such problems are apparent. >> >> Did you modify the CFLAGS or otherwise change the level of >> optimization used by the compiler? > > No CFLAGS were changed or anything else. It's a very standard install. > >>> I ran ktrace httpd -X >>> >>> Then when I try to open the phpMyAdmin/index.php page in a browser >>> httpd seg faults. >>> >>> Here is the tail of kdump from the ktrace.out from the above ktrace. >>> >>> .... >>> 1372 httpd CALL gettimeofday(0xbfbf7158,0) >>> 1372 httpd RET gettimeofday 0 >>> 1372 httpd CALL lstat(0xbfbf75b0,0xbfbf70f0) >>> 1372 httpd NAMI "/usr" >>> 1372 httpd RET lstat 0 >>> 1372 httpd CALL lstat(0xbfbf75b0,0xbfbf70f0) >>> 1372 httpd NAMI "/usr/local" >>> 1372 httpd RET lstat 0 >>> 1372 httpd CALL lstat(0xbfbf75b0,0xbfbf70f0) >>> 1372 httpd NAMI "/usr/local/www" >>> 1372 httpd RET lstat 0 >>> 1372 httpd CALL lstat(0xbfbf75b0,0xbfbf70f0) >>> 1372 httpd NAMI "/usr/local/www/phpMyAdmin" >>> 1372 httpd RET lstat 0 >>> 1372 httpd CALL lstat(0xbfbf75b0,0xbfbf70f0) >>> 1372 httpd NAMI "/usr/local/www/phpMyAdmin/libraries" >>> 1372 httpd RET lstat 0 >>> 1372 httpd CALL lstat(0xbfbf75b0,0xbfbf70f0) >>> 1372 httpd NAMI "/usr/local/www/phpMyAdmin/libraries/url_generating.lib.php" >>> 1372 httpd RET lstat 0 >>> 1372 httpd CALL open(0x845eda8,0,0x1b6) >>> 1372 httpd NAMI "/usr/local/www/phpMyAdmin/libraries/url_generating.lib.php" >>> 1372 httpd RET open 4 >>> 1372 httpd CALL fstat(0x4,0x8102748) >>> 1372 httpd RET fstat 0 >>> 1372 httpd CALL lseek(0x4,0,0,0,0x1) >>> 1372 httpd RET lseek 0 >>> 1372 httpd CALL read(0x4,0x82e3028,0x2000) >>> 1372 httpd GIO fd 4 read 4096 bytes >>> ">> /* $Id: url_generating.lib.php,v 2.12.2.1 2006/09/26 19:23:24 lem9 Exp $ */ >>> // vim: expandtab sw=4 ts=4 sts=4: >>> >>> >>> /** >>> * URL/hidden inputs generating. >>> */ >>> >>> >>> /** >>> * Generates text with hidden inputs. >>> * >>> * @see PMA_generate_common_url() >>> * @param string optional database name >>> * @param string optional table name >>> * @param int indenting level >>> * >>> * @return string string with input fields >>> * >>> * @global string the current language >>> * @global string the current conversion charset >>> * @global string the current connection collation >>> * @global string the current server >>> * @global array the configuration array >>> * @global boolean whether recoding is allowed or not >>> * >>> * >>> * @access public >>> * >>> * @author nijel >>> */ >>> function PMA_generate_common_hidden_inputs($db = '', $table = '', $indent = 0, $skip = array()) >>> { >>> if (is_array($db)) { >>> $params =& $db; >>> $_indent = empty($table) ? $indent : $table; >>> $_skip = empty($indent) ? $skip : $indent; >>> $indent =& $_indent; >>> $skip =& $_skip; >>> } else { >>> $params = array(); >>> if (isset($db) && strlen($db)) { >>> $params['db'] = $db; >>> } >>> if (isset($table) && strlen($table)) { >>> $params['table'] = $table; >>> } >>> } >>> >>> if (! empty($GLOBALS['server']) >>> && $GLOBALS['server'] != $GLOBALS['cfg']['ServerDefault']) { >>> $params['server'] = $GLOBALS['server']; >>> } >>> if (empty($_COOKIE['pma_lang']) >>> && ! empty($GLOBALS['lang'])) { >>> $params['lang'] = $GLOBALS['lang']; >>> } >>> if (empty($_COOKIE['pma_charset']) >>> && ! empty($GLOBALS['convcharset'])) { >>> $params['convcharset'] = $GLOBALS['convcharset']; >>> } >>> if (empty($_COOKIE['pma_collation_connection']) >>> && ! empty($GLOBALS['collation_connection'])) { >>> $params['collation_connection'] = $GLOBALS['collation_connection']; >>> } >>> >>> $params['token'] = $_SESSION[' PMA_token ']; >>> >>> if (! is_array($skip)) { >>> if (isset($params[$skip])) { >>> unset($params[$skip]); >>> } >>> } else { >>> foreach ($skip as $skipping) { >>> if (isset($params[$skipping])) { >>> unset($params[$skipping]); >>> } >>> } >>> } >>> >>> $spaces = str_repeat(' ', $indent); >>> >>> $return = ''; >>> foreach ($params as $key => $val) { >>> $return .= $spaces . '' . "\\n"; >>> } >>> >>> return $return; >>> } >>> >>> /** >>> * Generates text with URL parameters. >>> * >>> * >>> * // note the ? >>> * echo 'script.php?' . PMA_generate_common_url('mysql', 'rights'); >>> * // produces with cookies enabled: >>> * // script.php?db=mysql&table=rights >>> * // with cookies disabled: >>> * // script.php?server=1&lang=en-utf-8&db=mysql&table=rights >>> * >>> * $params['myparam'] = 'myvalue'; >>> * $params['db'] = 'mysql'; >>> * $params['table'] = 'rights'; >>> * // note the missing ? >>> * echo 'script.php' . PMA_generate_common_url($params); >>> * // produces with cookies enabled: >>> * // script.php?myparam=myvalue&db=mysql&table=rights >>> * // with cookies disabled: >>> * // script.php?server=1&lang=en-utf-8&myparam=myvalue&db=mysql&table=rights >>> * >>> * // note the missing ? >>> * echo 'script.php' . PMA_generate_common_url(); >>> * // produces with cookies enabled: >>> * // script.php >>> * // with cookies disabled: >>> * // script.php?server=1&lang=en-utf-8 >>> * >>> * >>> * @param mixed assoc. array with url params or optional string with database name >>> * if first param is an array there is also an ? prefixed to the url >>> * @param string optional table name only if first param is array >>> * @param string character to use instead of '&' for deviding >>> * multiple URL parameters from each other >>> * >>> * @return string string with URL parameters >>> * >>> * @global string the current language >>> * @global string the current conversion charset >>> * @global string the current connection collation >>> * @global string the current server >>> * @global arra" >>> 1372 httpd RET read 6467/0x1943 >>> 1372 httpd CALL read(0x4,0x82e3028,0x2000) >>> 1372 httpd GIO fd 4 read 0 bytes >>> "" >>> 1372 httpd RET read 0 >>> 1372 httpd CALL read(0x4,0x82e3028,0x2000) >>> 1372 httpd GIO fd 4 read 0 bytes >>> "" >>> 1372 httpd RET read 0 >>> 1372 httpd CALL close(0x4) >>> 1372 httpd RET close 0 >>> 1372 httpd PSIG SIGSEGV SIG_DFL >>> >>> >>> I moved url_generating.lib.php to url_generating.lib.php.sav and >>> copied url_generating.lib.php.sav to a new url_generating.lib.php. >>> Same thing happens. >>> >>> I tried the latest phpMyAdmin-2.9.2 and it does the exact same thing. >>> >>> It always seg faults in the exact same place in the exact same way. >>> >>> /var/log/messages file gets: >>> Feb 3 16:07:38 testbox kernel: pid 8512 (httpd), uid 80: exited on signal 11 >> Hmmm... a SEGV in apache or one of it's loaded modules should result >> in a core file in the cwd of the apache process. The general way to >> switch that behaviour off is by using the limits(1) command to set >> coredumpsize=0 -- and you can use /etc/login.conf to set limits for >> a whole class of users. If the apache startup scripts >> are running eg: >> >> eval `limits -e -C daemon` >> >> or similar that might be the cause. However, the default settings >> are 'coredumpsize=unlimited' for all, and I guess you'ld know if you'ld >> changed any of that sort of thing. >> >> Hmmm... cwd for the Apache process is set to the root directory, like >> all good daemons should. You can see that by: >> >> fstat -p `cat /var/run/httpd.pid` >> >> For very obvious security reasons, the root directory should not >> be writable by daemon processes with network listeners (and conversely, >> daemons should never be run as root or any other UID with write access, >> well, anywhere much). In this case, however, and strictly for testing >> purposes, so long as it's on a machine not accessible from the Internet, >> temporarily making the root dir writable by the apache process could help >> get you a core file to analyse. > > I changed / to mode 777 and reran the test. Same seg fault and still no core file. > When I say there is no core file I have checked with find / -name "*.core" > and there are no core files anywhere on the system. > > >>> /var/log/httpd-errors gets: >>> [Sat Feb 3 16:07:39 2007] [notice] child pid 8512 exit signal Segmentation fault (11) >>> >>> I am out of ideas on what to try next. Anyone else have any suggestions? >> Can you try unmounting and fsck'ing the partition (fsck -f /dev/adXsYz) >> where url_generating.lib.php lives? > > I thought by creating a new url_generating.lib.php file that would test the problem > of there being a bad spot on the disk. fsck runs clean. > >> Given that the error you are seeing is so repeatable, it is unlikely >> to be a hardware fault, but it may be worth running a cycle or two >> of memtest86 to see if it picks up anything. >> >> Otherwise the only thing I can think to try is the rather blunt approach >> of recompiling/reinstalling the phpMyAdmin port and everything it depends >> on: >> >> portupgrade -Rfi phpMyAdmin > > > I ran portupgrade -Rfv phpMyAdmin. It has a lot of dependencies > so it took a long time to finish and I didn't want to sit in front > of it and answer yes to all the questions. > > > It still does the exact same thing. > > I'm stumped. I guess I'll try a new install on a different system. > > Thanks, > Terry Todd It's a memory access issue most likely (signal 11), so making sure that all of its dependencies are current would be the first order of business. Don't forget to restart the http daemon that's using php so it can reload the libraries / dependencies. Next I'd check for memory errors on your machine; memtest86+ can solve that. Finally, (if possible) I'd see if you could trace down the exact line of code where it segfaulted (if it's a consistent location where it fails) in the phpMyAdmin program and then send it upstream to the maintainer via a bug report. -Garrett