php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33002 IMAP PHP connection crash Apache 2
Submitted: 2005-05-10 23:00 UTC Modified: 2005-05-11 21:52 UTC
From: netadmin at vcsn dot com Assigned:
Status: Not a bug Package: IMAP related
PHP Version: 4.3.11 OS: Linux 2.4.29
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: netadmin at vcsn dot com
New email:
PHP Version: OS:

 

 [2005-05-10 23:00 UTC] netadmin at vcsn dot com
Description:
------------
I've seen some postings about this problem but it appears the issue is never followed up and thus gets closed- so I'm posting it again since this is a high priority issue for me:

My environment is Apache 2.0.54 (I have also tried .47 and .49), PHP 4.3.11 (I have also tried, .1, .5, .8, and .10), Horde's IMP product (version 3.2.1 and version 4 with the appropriate Horde version respectively), Postgres 8.0.2 (migrated from 7.1.2- all data is intact and I do see database connections) and the UW c-client (built from 4.58 and 4.63).  The OS is Linux 2.4.29 (upgrade slackware 8 disto).

PHP appear's (I think) to be SIGSEGV'ing Apache when IMAP is being used.  Here is the gdb output that I get with different combinations of the version's I specified about [inserted below]

(note that the last version I tried was .5 but I will repeat 
with the lastest snapshot if requested since it also faulted)



Reproduce code:
---------------
As posted in a previous bug report, the following script will fault and generate a SIGSEGV in an Apache process and log it:

<?php
  $mbox=imap_open("{127.0.0.1:143}INBOX", "demo", "x");
?>


Expected result:
----------------
I actually am not sure since I borrowed the code and I'm not a PHP programmer.  The way I was diagnosed the problem was by using my sniffer to watch port 143 connections.  I would expect to see a connection to the IMAP server is things were working properly.

Actual result:
--------------
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run -DONE_PROCESS -DSSL
Starting program: /www2/bin/httpd -DONE_PROCESS -DSSL
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 12274)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 12274)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2  0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3  0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4  0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2
#5  0x403a647f in __getprotobyname_r (name=0x40767d84 "tcp", resbuf=0x403d9b48, buffer=0x83fd720 "?O=@?2=\b", buflen=1024, result=0xbfff6528)
    at ../nss/getXXbyYY_r.c:200
#6  0x403a632d in getprotobyname (name=0x40767d84 "tcp") at ../nss/getXXbyYY.c:145
#7  0x406e838a in tcp_socket_open (family=2, adr=0x8442d50, adrlen=4, port=143, tmp=0xbfff671c "\221+D\b|o??\206?n@dR\234@|o??A?n@\206k???\233v@\n",
    ctr=0xbfff6718, hst=0x8442d45 "vcsn.com") at tcp_unix.c:225
#8  0x406e81ee in tcp_open (host=0xbfff6fec "vcsn.com", service=0x0, port=143) at tcp_unix.c:184
#9  0x406f9913 in net_open_work (dv=0x407c53c0, host=0xbfff6fec "vcsn.com", service=0xbfff736e "imap", port=143, portoverride=143, flags=0)
    at mail.c:5967
#10 0x406f8113 in net_open (mb=0xbfff6fec, dv=0x0, port=143, ssld=0x0, ssls=0x407ab92c "*imaps", sslp=993) at mail.c:5938
#11 0x4070a652 in imap_open (stream=0x8442a98) at imap4r1.c:823
#12 0x406ed6f9 in mail_open (stream=0x8442a98, name=0x83f9364 "{vcsn.com:143/imap/notls}", options=0) at mail.c:1217
#13 0x405e25fb in php_imap_do_open (ht=4, return_value=0x8397c4c, this_ptr=0x0, return_value_used=1, persistent=0)
    at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:734
#14 0x405e26a9 in zif_imap_open (ht=4, return_value=0x8397c4c, this_ptr=0x0, return_value_used=1)
    at /root/src/INSTALLED/php-4.3.5/ext/imap/php_imap.c:755
#15 0x406d88d3 in execute (op_array=0x846474c) at /root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1623
#16 0x406d8a4a in execute (op_array=0x843bc34) at /root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1665
#17 0x406d8a4a in execute (op_array=0x844e13c) at /root/src/INSTALLED/php-4.3.5/Zend/zend_execute.c:1665
#18 0x406c6cfe in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/src/INSTALLED/php-4.3.5/Zend/zend.c:889
#19 0x4069e635 in php_execute_script (primary_file=0xbffff668) at /root/src/INSTALLED/php-4.3.5/main/main.c:1731
#20 0x406e002f in php_handler (r=0x8374ee8) at /root/src/INSTALLED/php-4.3.5/sapi/apache2handler/sapi_apache2.c:561
#21 0x0809f669 in ap_run_handler (r=0x8374ee8) at config.c:152
#22 0x0809fbb3 in ap_invoke_handler (r=0x8374ee8) at config.c:364
#23 0x08087ea2 in ap_process_request (r=0x8374ee8) at http_request.c:249
#24 0x08083e0a in ap_process_http_connection (c=0x836aea0) at http_core.c:251
#25 0x080a8cc8 in ap_run_process_connection (c=0x836aea0) at connection.c:43
#26 0x080a8f8c in ap_process_connection (c=0x836aea0, csd=0x836adc8) at connection.c:176
#27 0x0809e2f0 in child_main (child_num_arg=0) at prefork.c:610
#28 0x0809e3ac in make_child (s=0x80ec7d0, slot=0) at prefork.c:650
#29 0x0809e4a1 in startup_children (number_to_start=5) at prefork.c:722
#30 0x0809e7a3 in ap_mpm_run (_pconf=0x80e7590, plog=0x811f670, s=0x80ec7d0) at prefork.c:941
#31 0x080a3fae in main (argc=3, argv=0xbffffa34) at main.c:618




Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-05-11 01:27 UTC] sniper@php.net
The crash obviously happens outside PHP code -> not PHP bug.

 [2005-05-11 08:11 UTC] netadmin at vcsn dot com
It is not **obvious** to me- isn't it possible for PHP to return data that could 'cause a crash subsequently??  It would really be more helpful if you could point me to what you see **is** 'causing the crash so I can test and report back.
 [2005-05-11 11:23 UTC] jorton@php.net
We've seen this before, it's a bug in how Slackware build nss_db: 

#1  0x409f4e1e in db_open () from /lib/libnss_db.so.2
#2  0x409f4ed0 in internal_setent () from /lib/libnss_db.so.2
#3  0x409f390e in _nss_db_endprotoent () from /lib/libnss_db.so.2
#4  0x409f3b78 in _nss_db_getprotobyname_r () from /lib/libnss_db.so.2

that means that nss_db.so is built using a non-unique-name-ified version of BDB, which is doomed to failure.  You should report this bug to the Slackware maintainers.
 [2005-05-11 21:52 UTC] netadmin at vcsn dot com
Ahhh, I see.  Ok I will rebuild my box on a newer version and see what my mileage is.  8.0 is an old build so I'll see how 10.1 faires tonight and I will update this bug for completeness.  Thanks!
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Wed Feb 05 17:01:30 2025 UTC