Thanks for this very detailed report, setting it to feedback to await the backtrace.

Derick

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.

provided gdb feedback.

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.

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

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.

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

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.

Keep this at 'feedback' until you can get us that GDB backtrace..

#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

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.

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'

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

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);
?>

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

Yes, I am sure. Please try it yourself.

--Jani

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).

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

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)

Apparently this really isn't PHP bug after all.. :)
(but keeping this as feedback for now per user request)

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)

Not PHP problem, no feedback -> closing.