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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: aguilr at alum dot rpi dot edu
New email:
PHP Version: OS:

 

 [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 17:01:29 2024 UTC