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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 13:01:30 2024 UTC