php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26929 mysql_connect() segfaults php/apache
Submitted: 2004-01-16 04:23 UTC Modified: 2004-02-20 03:07 UTC
From: aguilr at alum dot rpi dot edu Assigned:
Status: Not a bug Package: MySQL related
PHP Version: 4.3.4 OS: Debian GNU/Linux 3.0r2
Private report: No CVE-ID: None
 [2004-01-16 04:23 UTC] aguilr at alum dot rpi dot edu
Description:
------------
Hello,

I've been working on this problem for about four days and haven't been able to find a bug report or newsgroup post describing how to fix it.

Basically, things compile and install fine, but as soon as mysql_connect() is run, PHP segfaults.

I also had to add --disable-pear in my configure line because "make install" would segfault when running install-pear-installer.

Here's my configure line:

APP_LOCATION=/opt/apps
APP_PATH=${APP_LOCATION}/php/4.3.4
HTTPD_LOCATION=${APP_LOCATION}/httpd/2.0.48

./configure --prefix=${APP_PATH} --disable-static --with-mysql=${APP_LOCATION}/mysql/4.0.17 --with-mysql-sock=/var/run/mysqld/mysqld.sock --with-apxs2=${HTTPD_LOCATION}/bin/apxs --with-gd --with-jpeg-dir --with-png-dir --with-freetype-dir --with-tiff-dir --with-zlib-dir --with-expat-dir=${APP_LOCATION}/expat/1.95.7 --with-xslt-sablot=${APP_LOCATION}/sablotron/1.0.1 --enable-xslt=shared --enable-track-vars --with-gettext --with-curl=${APP_LOCATION}/curl/7.10.8 --with-xml --with-dom --with-iconv-dir=${APP_LOCATION}/libiconv/1.9.1 --with-iconv=${APP_LOCATION}/libiconv/1.9.1 --with-db4=${APP_LOCATION}/db/4.0.14 --disable-pear --enable-debug

Apache2 works great on its own and MySQL is accepting connections from another PHP installation jsut fine.  Any help would be *much* appreciated!


Reproduce code:
---------------
<?php

$conn = mysql_connect("localhost", "username", "password");

print "I will not reach this line <br />";

mysql_select_db("nh", $conn);

$res = mysql_query("SELECT username FROM depalma_user");

while($row = mysql_fetch_array($res)) {
  print row['username'] . "<br />";
}

?>

Expected result:
----------------
user1
user2
user3
[...]

Actual result:
--------------
Here's a gdb backtrace:

#0  0x00000000 in ?? ()
#1  0x40553928 in _nss_db_getspnam_r () from /lib/libnss_db.so.2
#2  0x405539e0 in _nss_db_getspnam_r () from /lib/libnss_db.so.2
#3  0x4055311e in _nss_db_endservent () from /lib/libnss_db.so.2
#4  0x405533b3 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2
#5  0x40513a83 in getservbyname_r () from /lib/libc.so.6
#6  0x40513931 in getservbyname () from /lib/libc.so.6
#7  0x4007426d in mysql_once_init ()   from /opt/apps/mysql/4.0.17/lib/mysql/libmysqlclient.so.12
#8  0x40076a80 in mysql_init ()   from /opt/apps/mysql/4.0.17/lib/mysql/libmysqlclient.so.12
#9  0x080b4d36 in ?? ()
#10 0x080b5055 in ?? ()
#11 0x081a3bb2 in ?? ()
#12 0x08190834 in ?? ()
#13 0x08154e3c in ?? ()
#14 0x081aa977 in ?? ()
#15 0x4044c14f in __libc_start_main () from /lib/libc.so.6

An strace reveals:

# strace -p 16389
[...]
close(9)                                = 0open("/opt/apps/httpd/2.0.48/lib/libdb3.so.3", O_RDONLY) = -1 ENOENT (No such file or directory)open("/opt/apps/db/4.0.14/lib/libdb3.so.3", O_RDONLY) = -1 ENOENT (No such file or directory)open("/opt/apps/httpd/2.0.48/lib/libdb3.so.3", O_RDONLY) = -1 ENOENT (No such file or directory)open("i686/mmx/libdb3.so.3", O_RDONLY)  = -1 ENOENT (No such file or directory)open("i686/libdb3.so.3", O_RDONLY)      = -1 ENOENT (No such file or directory)open("mmx/libdb3.so.3", O_RDONLY)       = -1 ENOENT (No such file or directory)open("libdb3.so.3", O_RDONLY)           = -1 ENOENT (No such file or directory)open("/usr/lib/libdb3.so.3", O_RDONLY)  = 9read(9, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\311\0"..., 1024) = 1024fstat64(9, {st_mode=S_IFREG|0644, st_size=684092, ...}) = 0old_mmap(NULL, 687628, PROT_READ|PROT_EXEC, MAP_PRIVATE, 9, 0) = 0x40832000mprotect(0x408d9000, 3596, PROT_NONE)   = 0old_mmap(0x408d9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 9, 0xa6000) = 0x408d9000close(9)                                = 0munmap(0x40651000, 32390)               = 0--- SIGSEGV (Segmentation fault) ---



Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-16 06:07 UTC] georg@php.net
It's not a php (and probably not a mysql) bug. Please read 
http://bugs.mysql.com/bug.php?id=1338 and test it with 
official mysql binaries (if the problem still exists 
reopen #1338 on bugs.mysql.com) 
 [2004-01-22 22:17 UTC] aguilr at alum dot rpi dot edu
I added a comment to the mysql bug database a few days ago, but have not heard back.  As a suggestion from that bug report, I upgraded to Debian/Sarge, which still exhibits the same segfault.

From the strace and the gdb backtrace, I'm guessing it has something to do with:

/usr/lib/libdb3.so.3 

or 

/lib/libnss_db.so.2

Or, more likely, a db conflict since it seems that db2 and db3 are being used.

Any clues would be great!

Thanks.
 [2004-02-20 03:07 UTC] aguilr at alum dot rpi dot edu
Looks like this is, indeed, a debian issue.  I was able to work around the problem by modifying my /etc/nsswitch.conf file so that bdb isn't accessed when looking for whatever was being queried on the machine.  For example, the line:

hosts:          db files dns

was changed to:

hosts:          files dns

That fixed the problem.  

Thanks for the help!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 11:01:30 2024 UTC