|  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
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
10 + 40 = ?
Subscribe to this entry?

 [2004-01-16 04:23 UTC] aguilr at alum dot rpi dot edu

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:


./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:

$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:

Actual result:
Here's a gdb backtrace:

#0  0x00000000 in ?? ()
#1  0x40553928 in _nss_db_getspnam_r () from /lib/
#2  0x405539e0 in _nss_db_getspnam_r () from /lib/
#3  0x4055311e in _nss_db_endservent () from /lib/
#4  0x405533b3 in _nss_db_getservbyname_r () from /lib/
#5  0x40513a83 in getservbyname_r () from /lib/
#6  0x40513931 in getservbyname () from /lib/
#7  0x4007426d in mysql_once_init ()   from /opt/apps/mysql/4.0.17/lib/mysql/
#8  0x40076a80 in mysql_init ()   from /opt/apps/mysql/4.0.17/lib/mysql/
#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/

An strace reveals:

# strace -p 16389
close(9)                                = 0open("/opt/apps/httpd/2.0.48/lib/", O_RDONLY) = -1 ENOENT (No such file or directory)open("/opt/apps/db/4.0.14/lib/", O_RDONLY) = -1 ENOENT (No such file or directory)open("/opt/apps/httpd/2.0.48/lib/", O_RDONLY) = -1 ENOENT (No such file or directory)open("i686/mmx/", O_RDONLY)  = -1 ENOENT (No such file or directory)open("i686/", O_RDONLY)      = -1 ENOENT (No such file or directory)open("mmx/", O_RDONLY)       = -1 ENOENT (No such file or directory)open("", O_RDONLY)           = -1 ENOENT (No such file or directory)open("/usr/lib/", 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) ---


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-16 06:07 UTC]
It's not a php (and probably not a mysql) bug. Please read and test it with 
official mysql binaries (if the problem still exists 
reopen #1338 on 
 [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:




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

Any clues would be great!

 [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-2023 The PHP Group
All rights reserved.
Last updated: Wed Jun 07 08:03:39 2023 UTC