php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18104 imap_open() results in apache child pid exit segfaul sig (11)
Submitted: 2002-07-02 00:46 UTC Modified: 2002-09-11 11:32 UTC
From: lnxgeek at us dot ibm dot com Assigned:
Status: Not a bug Package: IMAP related
PHP Version: 4.2.1 OS: Red Hat Linux 7.3
Private report: No CVE-ID: None
 [2002-07-02 00:46 UTC] lnxgeek at us dot ibm dot com
Description:
------------

  With php 4.2.1 or 4.1.2 and c-client 2001a or current c-client devel snap shot I cannot use any imap_open() calls to cyrus 2.1.5. Attempted imap_open() calls result in an error being logged by apache in error_log:

[notice] child pid 27897 exit signal Segmentation fault (11)
[notice] child pid 27902 exit signal Segmentation fault (11)
[notice] child pid 27901 exit signal Segmentation fault (11)

followed by a 'Page contains no data' error in the browser.

Environment:
------------

  Red Hat 7.3
  php-4.2.1 compiled from src
  imap-2002.DEV.SNAP-0206241612 (c-client) compiled from src
  cyrus-sasl-2.1.5 compiled from src
  cyrus-imapd-2.1.5 compiled from src

Also Tried:
-----------

  php-4.1.2-7 RPMS from Red Hat 7.3
  imap-devel 2001a (c-client) from Red Hat 7.3

Config:
-------

  I have RH 7.3 with Cyrus IMAP and Cyrus-SASL compiled from source and installed fine. IMAP clients, Mozilla, Evo, fetchmail, etc, have no problems connecting to my imapd via imap or imaps. I am using a self signed cert but have tested with imaps and cyrus tls_cert_* options disabled. (ie: I've tested without cyrus imapd loading any type of SSL/TLS support).

Test Case and Results
----------------------

  I have the following test.php script running with php 4.2.1 and c-client 2002 DEV SNAP on the same Red Hat 7.3 server with Cyrus IMAPd 2.1.5:

<pre>
<?php
$ref = imap_open("{localhost:143}", "lnxgeek", "passwd", "OP_HALFOPEN")
  or die ("Failed imap_open with: ".imap_last_error());
print "imap connection opened!";
imap_close($ref);
?>
</pre>

I have also tried the following $server parms for imap_open(). The results of each test are listed in [].

{localhost:143} [self cert err]
{localhost:143/imap} [self cert err]
{localhost:143/imap/notls} [segfalt sig 11]
{localhost:143/imap/novalidate-cert} [segfault sig 11]
{localhost:143/imap/notls/novalidate-cert} [segfault sig 11]
{localhost:993} [no connect]
{localhost:993/imap} [no connect]
{localhost:993/imap/ssl} [self cert error]
{localhost:993/imap/ssl/novalidate-cert} [segfault sig 11]
{localhost:993/imap/tls/novalidate-cert} [no connect]

The imtest client provided with cyrus has no problems connecting via imap or imaps using DIGEST, CRAM, or PLAIN passwords.

Additional Trouble Shooting
----------------------------

  With the cyrus imapd running imap and imaps on the host 'ogg.raleigh.ibm.com', I attempted the same test script from a stock Red Hat 7.3 install. By default Red Hat 7.3 uses imap-devel 2001a (c-client) and php-4.1.2-7. Repeating the same tests as above resulted in the same errors shown.

Checking the logs of my cyrus server I can see that all connections were always accepted. For example I will typically see:

Jul  2 00:33:11 ogg imapd[28137]: mydelete: starting txn 2147483718
Jul  2 00:33:11 ogg imapd[28137]: mydelete: committing txn 2147483718
Jul  2 00:33:11 ogg imapd[28137]: mystore: starting txn 2147483719
Jul  2 00:33:11 ogg imapd[28137]: mystore: committing txn 2147483719
Jul  2 00:33:11 ogg imapd[28137]: starttls: TLSv1 with cipher DES-CBC3-SHA (168/168 bits new) no authentication

This shows a good connection has been made but at this point the apache child segfaults. Eventually the cyrus imapd session times out and closes.

GDB BackTrace
-------------

Next step: build php 4.2.1 with debug enabled and provide a gdb backtrace. 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-02 02:21 UTC] derick@php.net
Thanks for this very detailed report, setting it to feedback to await the backtrace.

Derick
 [2002-07-02 02:39 UTC] lnxgeek at us dot ibm dot com
Oops, apparently my second post was lost. Tried to get a bt but could not:

1) in bash ulimit -c unlimited
2) run ulimit -c to verify setting
3) built and installed php 4.2.1 with --enable-debug
4) start httpd with /usr/sbin/httpd -X -DHAVE_PHP4
5) run test script, get 'page contains no data'
6) run find / -fstype ext3 -name core* but none found.

Also, with --enable-debug in php 4.2.1 I no longer see the segfault error in error_log BUT I do still see the page contains no data errors coming from the browser which indecates that process is still segfaulting.

Also tried the gdb httpd method where I enter 'run -X -DHAVE_PHP4 at the gdb prompt. Again, no back trace. Hints as to what I'm doing wrong are welcome. 

I did forget to say that I'm running the apache-1.3.23-14 provided with Red Hat 7.3.
 [2002-07-02 02:39 UTC] lnxgeek at us dot ibm dot com
provided gdb feedback.
 [2002-07-02 04:12 UTC] lnxgeek at us dot ibm dot com
Another fun thing I did to see if this would work is I checked out the current php4/ext/imap/* files from CVS tonight and added them to the php 4.2.1 src replacing the files that were there. 

Built again with --enable-debug and attempted all the tests documented above. Received the same results. *sigh* Now it's time for sleep. Still cannot get a backtrace. Any hints on doing so would be great.
 [2002-07-02 08:42 UTC] sniper@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.

There you can find out how to get backtrace without a core file..

 [2002-07-02 11:40 UTC] lnxgeek at us dot ibm dot com
Sniper - Thanks much for the suggestions. I've followed the directions as indecated in my updates of last night but am not able to get a core file. 

Is it expected that with --enable-debug that errors no longer appear in /var/log/http/error_log ?

Do you have any suggestions in addition to what is at that URL for getting a core dump? I agree, a core dump is needed to figure out more. It's just a matter of getting one and I'm looking for a bit of help on that from someone who has done core dumps with php/apache before.

Thanks much.
 [2002-07-02 13:16 UTC] sniper@php.net
Open this page: http://bugs.php.net/bugs-generating-backtrace.php

And look under the topic 'If you can't get a core file'
for the instructions how to get a backtrace.

We _do_not_ want any core file, we want the GDB backtrace..

 [2002-07-02 23:54 UTC] lnxgeek at us dot ibm dot com
Yup, I understand you don't want the core file. I know that _I_ want the core file so I can give you a bt. I'll try again. And yes, I already tried _both_ sets of directions. Neither one did me good.

That said, I've narrowed the problem down to issues with php 4.2.1 / 4.1.2 imap module. The segfault will ONLY happen when trying to use CRAM-MD5 mech for authentication. If the imapd does not advertise CRAM-MD5 then PLAIN is used and everything works as expected.

That said, I check out the mtest tool provided with imap-2001a and verified that mtest will correctly login to an imap server with CRAM-MD5. PHP however continues to segfault when trying to do the same login with CRAM-MD5. 

I'm fairly certain this narrows the issue down to somethig having to do with MD5 auth in php4/ext/imap/imap.c and NOT the imap-2001a c-client libs.

For a simple test case I recomend the script posted in this bug report and to verify it works against an imapd server that advertises MD5-CRAM. I'm using Cyrus IMAPd 2.1.5 with SASL 2.1.5 for my tests.
 [2002-07-02 23:59 UTC] sniper@php.net
Keep this at 'feedback' until you can get us that GDB backtrace..

 [2002-07-03 00:42 UTC] lnxgeek at us dot ibm dot com
#0  0x42080c14 in strnlen () from /lib/i686/libc.so.6
#1  0x42051e42 in vfprintf () from /lib/i686/libc.so.6
#2  0x4206dbf3 in vsprintf () from /lib/i686/libc.so.6
#3  0x4205a257 in sprintf () from /lib/i686/libc.so.6
#4  0x4096f751 in auth_md5_client (challenger=0x4098aa10 <imap_challenge>, responder=0x4098aab0 <imap_response>, 
    service=0x409f4cad "imap", mb=0xbfffcdb0, stream=0x8190be8, trial=0xbfffcd18, user=0xbfffd150 "lnxgeek") at auth_md5.c:107
#5  0x4098a690 in imap_auth (stream=0x8190be8, mb=0xbfffcdb0, tmp=0xbfffd550 "00000001 AUTHENTICATE CRAM-MD5", 
    usr=0xbfffd150 "lnxgeek") at imap4r1.c:884
#6  0x40989b58 in imap_open (stream=0x8190be8) at imap4r1.c:666
#7  0x40962226 in mail_open (stream=0x0, name=0x8190bb4 "{ogg.raleigh.ibm.com:143/imap/notls}", options=0) at mail.c:1058
#8  0x4094f1c0 in php_imap_do_open (ht=4, return_value=0x819317c, this_ptr=0x0, return_value_used=1, persistent=0) at php_imap.c:844
#9  0x4094f2cc in zif_imap_open (ht=4, return_value=0x819317c, this_ptr=0x0, return_value_used=1) at php_imap.c:874
#10 0x4043aef1 in abuf.0 () from /etc/httpd/modules/libphp4.so
#11 0x4044bb24 in abuf.0 () from /etc/httpd/modules/libphp4.so
#12 0x4045e402 in abuf.0 () from /etc/httpd/modules/libphp4.so
#13 0x40458d92 in abuf.0 () from /etc/httpd/modules/libphp4.so
#14 0x40459c00 in abuf.0 () from /etc/httpd/modules/libphp4.so
#15 0x40459c7a in abuf.0 () from /etc/httpd/modules/libphp4.so
#16 0x0805475d in ap_invoke_handler ()
#17 0x080671fc in process_request_internal ()
#18 0x08067273 in ap_process_request ()
#19 0x0805f4f7 in child_main ()
#20 0x0805f69a in make_child ()
#21 0x0805f7dd in startup_children ()
#22 0x0805fe30 in standalone_main ()
#23 0x08060723 in main ()
#24 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
 [2002-07-03 20:24 UTC] sniper@php.net
Using the imap-2002.DEV.SNAP-0206241612.tar.Z c-client lib
with PHP and the imapd from that same package does not 
cause any crash. Neither did it crash with the imap-2001a
c-client..

Try this PHP snapshot:

http://snaps.php.net/php4-latest.tar.gz

It would also help a bit if you could provide an account
for your server to test this.

That gdb backtrace does suggest that this crash happens in c-client, NOT in PHP. But please try that snapshot.




 [2002-07-03 23:47 UTC] lnxgeek at us dot ibm dot com
Building php4-latest.tgz fails on Red Hat 7.3 with an odd problem about not finding mysqlclient when clearly it should be able to find it. php 4.2.1 stable does not have this issue.

/usr/bin/ld: cannot find -lmysqlclient
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

[root@ogg php4-200207031800]# /sbin/ldconfig -v | grep mysql
/usr/lib/mysql:
	libmysqlclient.so.10 -> libmysqlclient.so.10.0.0
[root@ogg php4-200207031800]# 

I used the following ./configure line:

'./configure' \
'i386-redhat-linux' \
'--prefix=/usr' \
'--exec-prefix=/usr' \
'--bindir=/usr/bin' \
'--sbindir=/usr/sbin' \
'--sysconfdir=/etc' \
'--datadir=/usr/share' \
'--includedir=/usr/include' \
'--libdir=/usr/lib' \
'--libexecdir=/usr/libexec' \
'--localstatedir=/var' \
'--sharedstatedir=/usr/com' \
'--mandir=/usr/share/man' \
'--infodir=/usr/share/info' \
'--prefix=/usr' \
'--with-config-file-path=/etc' \
'--enable-force-cgi-redirect' \
'--enable-debug' \
'--enable-dbg=shared' \
'--with-dbg-profiler' \
'--enable-pic' \
'--disable-rpath' \
'--enable-inline-optimization' \
'--with-bz2' \
'--with-db3' \
'--with-curl' \
'--with-dom=/usr' \
'--with-exec-dir=/usr/bin' \
'--with-freetype-dir=/usr' \
'--with-png-dir=/usr' \
'--with-gd' \
'--enable-gd-native-ttf' \
'--with-ttf' \
'--with-gdbm' \
'--with-gettext' \
'--with-ncurses' \
'--with-gmp' \
'--with-iconv' \
'--with-jpeg-dir=/usr' \
'--with-mm' \
'--with-openssl' \
'--with-png' \
'--with-pspell' \
'--with-regex=system' \
'--with-xml' \
'--with-expat-dir=/usr' \
'--with-zlib' \
'--with-layout=GNU' \
'--enable-bcmath' \
'--enable-debugger' \
'--enable-exif' \
'--enable-ftp' \
'--enable-magic-quotes' \
'--enable-safe-mode' \
'--enable-sockets' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-discard-path' \
'--enable-track-vars' \
'--enable-trans-sid' \
'--enable-yp' \
'--enable-wddx' \
'--without-oci8' \
'--with-imap=shared' \
'--with-imap-ssl' \
'--with-kerberos=/usr/kerberos' \
'--with-ldap=shared' \
'--with-mysql=shared,/usr' \
'--with-pgsql=shared' \
'--with-snmp=shared,/usr' \
'--with-snmp=shared' \
'--enable-ucd-snmp-hack' \
'--with-unixODBC=shared' \
'--enable-memory-limit' \
'--enable-bcmath' \
'--enable-shmop' \
'--enable-versioning' \
'--enable-calendar' \
'--enable-dbx' \
'--enable-dio' \
'--enable-mcal' \
'--enable-mbstring' \
'--enable-mbstr-enc-trans' \
'--with-apxs=/usr/sbin/apxs' \
'--without-cyrus'
 [2002-07-06 13:20 UTC] lnxgeek at us dot ibm dot com
I tried building SNAP php4-200207060900 but it also fails to link mysqlclient libs correctly. Based on that I tried the following:

1) untar php-4.2.1.tar.gz
2) cp php4-200207060900/ext/imap/* php-4.2.1/ext/imap/
3) ./configure; make; make install;
4) restart httpd with -X and run gdb against it.

Here is the resulting back trace from php 4.2.1 with updated imap ext from php4-200207060900. 

I do NOT think this is a problem with c-client since the mtest program provided with c-client has NO problems logging in with CRAM-MD5. The php4 imap extention however will core apache every time when using CRAM-MD5. PLAIN mechs work fine in both mtest and php4.

#1  0x42051f32 in vfprintf () from /lib/i686/libc.so.6
#2  0x4206dce3 in vsprintf () from /lib/i686/libc.so.6
#3  0x4205a347 in sprintf () from /lib/i686/libc.so.6
#4  0x40918a61 in auth_md5_client (challenger=0x40933d20 <imap_challenge>, 
    responder=0x40933dc0 <imap_response>, service=0x4099dfad "imap", 
    mb=0xbfffcc40, stream=0x811fd50, trial=0xbfffcba8, 
    user=0xbfffcfe0 "lnxgeek") at auth_md5.c:107
#5  0x409339a0 in imap_auth (stream=0x811fd50, mb=0xbfffcc40, 
    tmp=0xbfffd3e0 "00000001 AUTHENTICATE CRAM-MD5", usr=0xbfffcfe0 "lnxgeek")
    at imap4r1.c:884
#6  0x40932e68 in imap_open (stream=0x811fd50) at imap4r1.c:666
#7  0x4090b536 in mail_open (stream=0x0, 
    name=0x812110c "{ogg.raleigh.ibm.com:143/imap/notls}", options=0)
    at mail.c:1058
#8  0x408f823c in php_imap_do_open (ht=4, return_value=0x8153a3c, 
    this_ptr=0x0, return_value_used=1, persistent=0) at php_imap.c:863
#9  0x408f8354 in zif_imap_open (ht=4, return_value=0x8153a3c, this_ptr=0x0, 
    return_value_used=1) at php_imap.c:893
#10 0x4043aef1 in abuf.0 () from /etc/httpd/modules/libphp4.so
#11 0x4044bb24 in abuf.0 () from /etc/httpd/modules/libphp4.so
#12 0x4045e402 in abuf.0 () from /etc/httpd/modules/libphp4.so
#13 0x40458d92 in abuf.0 () from /etc/httpd/modules/libphp4.so
---Type <return> to continue, or q <return> to quit---
#14 0x40459c00 in abuf.0 () from /etc/httpd/modules/libphp4.so
#15 0x40459c7a in abuf.0 () from /etc/httpd/modules/libphp4.so
#16 0x0805475d in ap_invoke_handler ()
#17 0x080671fc in process_request_internal ()
#18 0x08067273 in ap_process_request ()
#19 0x0805f4f7 in child_main ()
#20 0x0805f69a in make_child ()
#21 0x0805f7dd in startup_children ()
#22 0x0805fe30 in standalone_main ()
#23 0x08060723 in main ()
#24 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
 [2002-07-06 19:51 UTC] sniper@php.net
Like I said before, I can not reprocude this with the UW imapd. Can you provide an account for your server? 

My test script:

<?php
$mbox = imap_open("{localhost:143/imap/notls}", "user", "pass");
$status = imap_headers($mbox);
imap_close($mbox);
print_r($status);
?>


 [2002-07-06 21:07 UTC] lnxgeek at us dot ibm dot com
On your wu-imapd server can you verify that you are using CRAM-MD5 as the authentication mech? This bug is known not to occur when using PLAIN auth mechs. If you're not sure which mech you're using you can verify with with the mtest client from imap-2001a.

The cyrus-imapd 2.1.5 server is behind the IBM firewall. There's no way I can get you access to it. 

I tested the following combinations of c-client and php. All of them fail with apache sig 11 in the same way.

imap-2000-9 / php 4.2.1
imap-2000-9 / php 4.1.2-7
imap-2000c-15 / php 4.2.1
imap-2000c-15 / php 4.2.1
imap-2001a / php 4.2.1
imap-2002.DEV.SNAP-0206241612 / php 4.2.1
 [2002-07-06 21:25 UTC] sniper@php.net
Yes, I am sure. Please try it yourself.

--Jani

 [2002-07-06 21:35 UTC] lnxgeek at us dot ibm dot com
Can I get a test account on your wu-imapd server? I would like to verify the success you are seeing from a known failing system (my box).
 [2002-07-07 00:48 UTC] lnxgeek at us dot ibm dot com
I built php4-200207060900 with the following options:

'./configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-debug' '--with-openssl'
'--with-imap' '--with-imap-ssl' '--with-apxs=/usr/sbin/apxs'
'--without-cyrus' '--with-kerberos'

My c-client libs are ssl/kerberos enabled which is why I need those
two options. The rest is just path info.

I still get a segfault. Here is the back trace:

#0  0x42080d04 in strnlen () from /lib/i686/libc.so.6
#1  0x42051f32 in vfprintf () from /lib/i686/libc.so.6
#2  0x4206dce3 in vsprintf () from /lib/i686/libc.so.6
#3  0x4205a347 in sprintf () from /lib/i686/libc.so.6
#4  0x40586da1 in auth_md5_client (challenger=0x405a2060
    <imap_challenge>, responder=0x405a2100 <imap_response>,
    service=0x40652c8d "imap", mb=0xbfffbd60, stream=0x80f7be0,
    trial=0xbfffbcc8, user=0xbfffc100 "test")
    at auth_md5.c:107
#5  0x405a1ce0 in imap_auth (stream=0x80f7be0, mb=0xbfffbd60,
    tmp=0xbfffc500 "00000000 AUTHENTICATE CRAM-MD5",
    usr=0xbfffc100 "test") at imap4r1.c:884
#6  0x405a11a8 in imap_open (stream=0x80f7be0) at imap4r1.c:666
#7  0x40579876 in mail_open (stream=0x0, name=0x812bfac
    "{213.243.182.199:143/imap/notls}", options=0)
    at mail.c:1058
#8  0x40426c48 in php_imap_do_open (ht=3, return_value=0x80fb32c,
    this_ptr=0x0, return_value_used=1, persistent=0)
    at /root/php4-200207060900/ext/imap/php_imap.c:863
#9  0x40426d60 in zif_imap_open (ht=3, return_value=0x80fb32c,
    this_ptr=0x0, return_value_used=1)
    at /root/php4-200207060900/ext/imap/php_imap.c:893
#10 0x4056ecc1 in execute (op_array=0x80f663c) at
    /root/php4-200207060900/Zend/zend_execute.c:1587
#11 0x4055d4f8 in zend_execute_scripts (type=8, retval=0x0,
    file_count=3)
    at /root/php4-200207060900/Zend/zend.c:810
#12 0x4052a532 in php_execute_script (primary_file=0xbffff6b0) at
    /root/php4-200207060900/main/main.c:1388
#13 0x40573c1a in apache_php_module_main (r=0x80ed1c8,
    display_source_mode=0)
    at /root/php4-200207060900/sapi/apache/sapi_apache.c:55
#14 0x40574ac0 in send_php (r=0x80ed1c8, display_source_mode=0,
    filename=0x80eed78 "/var/www/html/test2.php")
    at /root/php4-200207060900/sapi/apache/mod_php4.c:550
#15 0x40574b2d in send_parsed_php (r=0x80ed1c8) at
    /root/php4-200207060900/sapi/apache/mod_php4.c:565
#16 0x0805475d in ap_invoke_handler ()
#17 0x080671fc in process_request_internal ()
#18 0x08067273 in ap_process_request ()
#19 0x0805f4f7 in child_main ()
#20 0x0805f69a in make_child ()
#21 0x0805f7dd in startup_children ()
#22 0x0805fe30 in standalone_main ()
#23 0x08060723 in main ()
#24 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
 [2002-07-07 01:14 UTC] lnxgeek at us dot ibm dot com
A little extra info that goes along with the prevous backtrace. Might be helpful.

(gdb) frame 10
#10 0x4056ecc1 in execute (op_array=0x80f2bdc) at /root/php4-200207060900/Zend/zend_execute.c:1587
1587							((zend_internal_function *) EX(function_state).function)->handler(EX(opline)->extended_value, EX(Ts)[EX(opline)->result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC);
(gdb) print (char *)(executor_globals.function_state_ptr->function)->common.function_name
$1 = 0x405cb13f "imap_open"
(gdb)
 [2002-07-08 02:16 UTC] sniper@php.net
Apparently this really isn't PHP bug after all.. :)
(but keeping this as feedback for now per user request)

 [2002-07-11 16:43 UTC] sniper@php.net
lnxgeek@us.ibm.com wrote:

cyrus sasl libs built into the openldap libs which of course 
get pulled into apache when loading mod_auth_ldap or pulled 
into php when building ldap.so were the root cause.

Removing mod_auth_ldap from the httpd.conf, building 
openldap using --without-cyrus-sasl, --disable-spasswd, and 
then rebuilding php 4.1.2 against the new ldap libs solved 
the problems. (libsasl.so.7 was no longer linked by apache or php4)


 [2002-09-11 11:32 UTC] sniper@php.net
Not PHP problem, no feedback -> closing.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 10:01:28 2024 UTC