Date: Tue, 6 Feb 2007 08:42:30 -0600 From: Terry Todd <tlt@badger.tltodd.com> To: freebsd-questions@freebsd.org Subject: Re: phpMyAdmin httpd segmentation fault Message-ID: <20070206084230.A31659@badger.tltodd.com> In-Reply-To: <20070206055549.A24465@badger.tltodd.com>; from tlt@badger.tltodd.com on Tue, Feb 06, 2007 at 05:55:49AM -0600 References: <20070203204156.A4743@badger.tltodd.com> <45C5A93A.8010501@infracaninophile.co.uk> <20070205055425.A68136@badger.tltodd.com> <45C7482D.2060103@u.washington.edu> <20070205231230.A9862@badger.tltodd.com> <45C82ABA.1010606@infracaninophile.co.uk> <20070206055549.A24465@badger.tltodd.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 06, 2007 at 07:14:02AM +0000, Matthew Seaman wrote:
> Terry Todd wrote:
> > On Mon, Feb 05, 2007 at 07:07:25AM -0800, Garrett Cooper wrote:
> >> 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
> >>>>> "<?php
> >>>>> /* $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 . '<input type="hidden" name="' . htmlspecialchars($key) . '" value="' . htmlspecialchars(\
> >>>>> $val) . '" />' . "\\n";
> >>>>> }
> >>>>>
> >>>>> return $return;
> >>>>> }
> >>>>>
> >>>>> /**
> >>>>> * Generates text with URL parameters.
> >>>>> *
> >>>>> * <code>
> >>>>> * // 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
> >>>>> * </code>
> >>>>> *
> >>>>> * @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.
>
> I am the maintainer for the phpMyAdmin port. Consider me already informed.
>
> > I took the hard drive out of the computer that was having the
> > problem and installed in a completely different computer.
> >
> > It still has the same exact problem in the same exact place.
> >
> > The only reference to url_generating.lib.php is on line 2682 of
> > phpMyAdmin/libraries/common.lib.php
> >
> > httpd is what actually segfaults when reading the file url_generating.lib.php.
>
> Given that I've seen no other reports of anything like this, either
> direct to me or to phpMyAdmin lists on sourceforge, and that I've
> got a number of phpMyAdmin installations happily working for various
> customers using various different Apache and PHP versions, I'm pretty
> certain that the root cause of your problem is something localised on
> your system.
>
> I think you've pretty well eliminated hardware faults (either memory
> or disk) as the cause. Therefore the prime suspect must be something
> within your local install. Two possibilities come to mind: (a) does
> your php installation contain all of the required functionality? (b)
> have you managed to place some sort of pathological statement in
> php.ini or config.inc.php Arguably though, anything like that which
> could cause segmentation violations in apache / PHP / phpMyAdmin is
> a bug in one or other of those packages.
>
> On option (a) the phpMyAdmin port depends on a number of PHP modules
> -- you need to have mysql, pcre and session but can optionally have
> the following:
>
> happy-idiot-talk:~:% pkg_info -r phpMyAdmin\* | grep php5
> Dependency: php5-5.2.0
> Dependency: php5-zlib-5.2.0
> Dependency: php5-session-5.2.0
> Dependency: php5-pcre-5.2.0
> Dependency: php5-openssl-5.2.0
> Dependency: php5-mysqli-5.2.0
> Dependency: php5-mysql-5.2.0
> Dependency: php5-mcrypt-5.2.0
> Dependency: php5-mbstring-5.2.0
> Dependency: php5-gd-5.2.0
> Dependency: php5-bz2-5.2.0
>
> On (b) I suggest comparing your php.ini and config.inc.php with the
> default ones installed with the respective ports and hashing out
> anything you've modified to see if you can identify what (if anything)
> in those files might be causing the problem.
>
> Quite frankly though, I'm doing no more than guessing at what the cause
> of the trouble is and I can't guarantee either of the above is going to
> get you results. There is undoubtedly some small, overlooked but vital
> thing which is the key to all this...
>
> Cheers,
>
> Matthew
>
> --
> Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
> Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
> Kent, CT11 9PW
>
on a)
testbox# pkg_info -r phpMyAdmin\* | grep php5
Dependency: php5-5.1.6_3
Dependency: php5-zlib-5.1.6_3
Dependency: php5-session-5.1.6_3
Dependency: php5-pcre-5.1.6_3
Dependency: php5-openssl-5.1.6_3
Dependency: php5-mysqli-5.1.6_3
Dependency: php5-mysql-5.1.6_3
Dependency: php5-mcrypt-5.1.6_3
Dependency: php5-mbstring-5.1.6_3
Dependency: php5-bz2-5.1.6_3
Dependency: php5-gd-5.1.6_3
testbox#
on b)
testbox# diff php.ini php.ini-dist
testbox#
testbox# diff config.inc.php config.inc.php.sample
13,14d12
< $cfg['Servers'][$i]['user'] = 'root';
< $cfg['Servers'][$i]['password'] = '********'; [actual password blotted out]
testbox#
Other programs like phpSysInfo work OK.
portupgrade -Rfv phpMyAdmin made no difference.
I also ran make buildworld and make installworld which also made
no difference.
The latest complete ktrace.out is attached to the email I sent to your personal email.
Terry Todd
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070206084230.A31659>