phpMyAdmin httpd segmentation fault
Matthew Seaman
m.seaman at infracaninophile.co.uk
Tue Feb 6 07:14:49 UTC 2007
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20070206/f69b1237/signature.pgp
More information about the freebsd-questions
mailing list