php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #30777 Apache/PHP/DB3/DB4/Subversion causes repeatable segfault
Submitted: 2004-11-13 21:19 UTC Modified: 2004-11-14 11:33 UTC
From: shire at tekrat dot com Assigned:
Status: Not a bug Package: Apache related
PHP Version: * OS: *
Private report: No CVE-ID: None
 [2004-11-13 21:19 UTC] shire at tekrat dot com
Description:
------------
I've noticed segfaults occuring both on the initial call of any php file or on the imap_open call, although the nature of the code/call seems to be irrelevent to the actual problem.  It becames apparent that the PHP/Apache/Subversion/DB3/DB4 combination becomes a problem.  Even with PHP/Apache/Subversion compiled with DB4, if a DB3.so is added to the system, then php/apache will begin to segfault.  This has been observed in php4.3.8 (faults on any php script) and php4.3.9(fault on imap_open).  it appears that php will try and load any db library it finds, rather than the latest module ie: db4 over db3.  This apparently causes a conflict/segfault in php/apache. 

Reproduce code:
---------------
You can reproduce this by compiling php/apache/subversion with DB4(required by subversion) and then adding db3.so to the system.

Expected result:
----------------
n/a


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-11-13 21:25 UTC] tony2001@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


 [2004-11-13 23:25 UTC] shire at tekrat dot com
Backtrace....

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 30943)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x40945928 in ?? ()
#2  0x409459e0 in ?? ()
#3  0x409443fe in ?? ()
#4  0x40944668 in ?? ()
#5  0x4037c7cf in getprotobyname_r () from /lib/libc.so.6
#6  0x4037c67d in getprotobyname () from /lib/libc.so.6
#7  0x4059c76a in tcp_socket_open (family=2, adr=0x8350608, adrlen=4, port=143,
    tmp=0xbfff5c5c "\223Å´\b¼äÿ¿f(Z@àÜ024:@¼äÿ¿!'Z@Æàÿ¿\234\fb@\n", ctr=0xbfff5c58, hst=0x835062e "xxxx.com")
    at tcp_unix.c:225
#8  0x4059c5ce in tcp_open (host=0xbfff652c "xxxx.com", service=0x0, port=143) at tcp_unix.c:184
#9  0x405af673 in net_open_work (dv=0x4067ba00, host=0xbfff652c "xxxxx.com", service=0xbfff68ae "imap", port=143,
    portoverride=143, flags=0) at mail.c:5947
#10 0x405adef3 in net_open (mb=0xbfff652c, dv=0x0, port=143, ssld=0x4067b840, ssls=0x40662bcc "*imaps", sslp=993)
    at mail.c:5918
#11 0x405c0062 in imap_open (stream=0x834c498) at imap4r1.c:823
#12 0x405a38d9 in mail_open (stream=0x834c498, name=0x829cb04 "{tekrat.com:143/imap/notls}", options=0) at mail.c:1206
#13 0x404b1418 in php_imap_do_open (ht=4, return_value=0x8337424, this_ptr=0x0, return_value_used=1, persistent=0)
    at /home/shire/install/php-4.3.9/ext/imap/php_imap.c:740
#14 0x404b14c9 in zif_imap_open (ht=4, return_value=0x8337424, this_ptr=0x0, return_value_used=1)
    at /home/shire/install/php-4.3.9/ext/imap/php_imap.c:761
#15 0x4058cdc3 in execute (op_array=0x829765c) at /home/shire/install/php-4.3.9/Zend/zend_execute.c:1642
#16 0x4058cf3a in execute (op_array=0x8295244) at /home/shire/install/php-4.3.9/Zend/zend_execute.c:1684
#17 0x4058cf3a in execute (op_array=0x81b9804) at /home/shire/install/php-4.3.9/Zend/zend_execute.c:1684
#18 0x4057b08e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /home/shire/install/php-4.3.9/Zend/zend.c:891
#19 0x40552c55 in php_execute_script (primary_file=0xbffff3d8) at /home/shire/install/php-4.3.9/main/main.c:1735
#20 0x4059449f in php_handler (r=0x81af140) at /home/shire/install/php-4.3.9/sapi/apache2handler/sapi_apache2.c:540
#21 0x080671f9 in ap_run_handler (r=0x81af140) at config.c:151
#22 0x08067743 in ap_invoke_handler (r=0x81af140) at config.c:358
#23 0x08064b06 in ap_process_request (r=0x81af140) at http_request.c:246
#24 0x08060a8a in ap_process_http_connection (c=0x81a9108) at http_core.c:250
#25 0x0806f658 in ap_run_process_connection (c=0x81a9108) at connection.c:42
#26 0x0806f91c in ap_process_connection (c=0x81a9108, csd=0x81a9030) at connection.c:175
#27 0x08065e80 in child_main (child_num_arg=0) at prefork.c:609
#28 0x08065f3c in make_child (s=0x809c310, slot=0) at prefork.c:649
#29 0x08066031 in startup_children (number_to_start=10) at prefork.c:721
#30 0x08066333 in ap_mpm_run (_pconf=0x809a570, plog=0x80c4618, s=0x809c310) at prefork.c:940
#31 0x0806baee in main (argc=2, argv=0xbffff7a4) at main.c:617
(gdb) 



here's the output of an strace call of httpd -X, while calling the same code as above....(summarized)
....
----[This is loading lidb4 when apache starts]----
open("/usr/local/apache2/lib/libdb-4.0.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/BerkeleyDB.4.0/lib/libdb-4.0.so", O_RDONLY) = 3
....
open("/usr/local/apache2/lib/libdb3.so.3", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/local/BerkeleyDB.4.0/lib/libdb3.so.3", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libdb3.so.3", O_RDONLY)  = 21
----[This is after the php is called, and php.so loads the libdb3.so]----

let me know if there's anything else I can provide...
 [2004-11-13 23:57 UTC] helly@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

You can not load more than one db* module in one process unless you configure them to have different names. That said i wonder how you could build your installation.
 [2004-11-14 01:44 UTC] shire at tekrat dot com
I think I'm being misunderstood.  PHP is loading the db3 shared object rather than the db4 library when both are present and when PHP was compiled with only the db4 library present.  This means that in order to run PHP/Apache/Subversion I have to remove db3 from the system, and can NEVER install db3.  Is this the correct functionality of PHP?  Is there a way to prevent php from loading the db3 library?  Thanks.
 [2004-11-14 11:33 UTC] helly@php.net
PHP only loads db3 if you configure it to do so. Also instead of db3 you can make php use db4. So still i can see no real problem but a configure one.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 26 12:01:30 2024 UTC