Bug #18104 Updated: imap_open() results in apache child pid exit segfaul sig (11)

ID: 18104 Updated by: sniper@php.net Reported By: lnxgeek@us.ibm.com -Status: Open +Status: Feedback Bug Type: IMAP related Operating System: Red Hat Linux 7.3 PHP Version: 4.2.1 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2002-07-03 00:42:42] lnxgeek@us.ibm.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-02 23:59:46] sniper@php.net Keep this at 'feedback' until you can get us that GDB backtrace.. ------------------------------------------------------------------------ [2002-07-02 23:54:17] lnxgeek@us.ibm.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 13:16:39] 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 11:40:08] lnxgeek@us.ibm.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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18104 -- Edit this bug report at http://bugs.php.net/?id=18104&edit=1