Bug 118137
Summary: | PHP imap_open crashes when remote servers used CRAM-MD5 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Per Steinar Iversen <persteinar.iversen> |
Component: | imap | Assignee: | John Dennis <jdennis> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.0 | CC: | dowdle, jorton, orkcu |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-05-12 01:24:50 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Per Steinar Iversen
2004-03-12 12:46:16 UTC
Thanks for the report. To speed up investigation can you get a core dump and a backtrace? echo "ulimit -c unlimited" >> /etc/sysconfig/httpd echo "CoreDumpDirectory /tmp" > /etc/httpd/conf.d/core.conf then restart httpd, and trigger the error. To get a backtrace, run: gdb /usr/sbin/httpd /tmp/core.<pid> and post the results of entering "where" into gdb. I did this now, but no core files: # service httpd stop Stopping httpd: [ OK ] # cat /etc/sysconfig/httpd ulimit -c unlimited # cat /etc/httpd/conf.d/core.conf CoreDumpDirectory /tmp # service httpd start Starting httpd: [ OK ] # wget http://localhost/imap.php --14:10:24-- http://localhost/imap.php => `imap.php' Resolving localhost... done. Connecting to localhost[127.0.0.1]:80... connected. HTTP request sent, awaiting response... End of file while parsing headers. Retrying. In the log: [Fri Mar 12 14:10:25 2004] [notice] child pid 2468 exit signal Segmentation fault (11) [Fri Mar 12 14:10:26 2004] [notice] child pid 2469 exit signal Segmentation fault (11) But no files in /tmp : # ls -al /tmp total 12 drwxrwxrwt 3 root root 4096 Mar 12 14:10 . drwxr-xr-x 21 root root 4096 Mar 1 12:45 .. drwx------ 2 root root 4096 Jan 1 1970 orbit-root Apologies, those instructions weren't right for RHEL3. Can you try: # service httpd stop # ulimit -c unlimited # /usr/sbin/httpd #0 0xb719fe00 in strnlen () from /lib/tls/libc.so.6 #1 0xb716e1f2 in vfprintf () from /lib/tls/libc.so.6 #2 0xb718a04c in vsprintf () from /lib/tls/libc.so.6 #3 0xb7174d3d in sprintf () from /lib/tls/libc.so.6 #4 0xb648a52f in auth_md5_client () from /usr/lib/php4/imap.so #5 0xb64b77e2 in imap_auth () from /usr/lib/php4/imap.so #6 0xb64b6e54 in imap_open () from /usr/lib/php4/imap.so #7 0xb649766f in mail_open () from /usr/lib/php4/imap.so #8 0xb647b0e2 in zm_info_imap () from /usr/lib/php4/imap.so #9 0xb647b33e in zif_imap_open () from /usr/lib/php4/imap.so #10 0xb6d696c8 in execute () from /etc/httpd/modules/libphp4.so #11 0xb6d5b026 in zend_execute_scripts () from /etc/httpd/modules/libphp4.so #12 0xb6d2fc73 in php_execute_script () from /etc/httpd/modules/libphp4.so #13 0xb6d6e338 in execute () from /etc/httpd/modules/libphp4.so #14 0x0807480c in ap_pass_brigade () #15 0x0807c349 in ap_core_translate () #16 0x08068685 in ap_run_handler () #17 0x08068c9f in ap_invoke_handler () #18 0x08065326 in ap_process_request () #19 0x0806095c in _start () #20 0x08271d58 in ?? () #21 0x00000004 in ?? () #22 0x08271d58 in ?? () #23 0xb6f722f7 in modperl_process_connection_handler () from /etc/httpd/modules/mod_perl.so #24 0x08072165 in ap_run_process_connection () #25 0x08066ba1 in ap_graceful_stop_signalled () #26 0x08066cf4 in ap_graceful_stop_signalled () #27 0x08066e16 in ap_graceful_stop_signalled () #28 0x0806763d in ap_mpm_run () #29 0x0806daef in main () This appears to be a bug due to poor coding practice in two unrelated packages. The function called immediately prior to this sprintf was hmac_md5(). There is a symbol conflict on hmac_md5(), since it is also defined by libsasl.so.7, so when imap.so is loaded, the wrong hmac_md5() might be called. The simplest place fix this is in the UW imap package, by making all the functions in auth_md5.c static. Is it likely that this will be patched in the UW imap package? A UW imap package was produced and Joe will be testing with it. If successful it will likely going into U3, its too late for U2. If you are stuck in the water and would like to test you can ftp the patched rpm here: ftp://people.redhat.com/jdennis/imap-2002d-8.i386.rpm I picked up this rpm and installed it but the PHP code still crashes when run through apache but not from the command line, the traceback looks the same as before too - is it necessary to rebuild php-imap also? In that case the imap-devel package is probably necessary too. Updated PHP packages which have bene rebuilt against the fixed imap packages are now available for test purposes from here: http://people.redhat.com/jorton/Taroon-php/ if you have further issues please let us know. hi, those php packages also resolve an "inconvenient" behaivor, i couldn't test it with RHEL because i can't access to it, so i use Whitebox for my servers. One of them is just for webmail, so i have instaled in it apache+php+Horde/IMP+mysql , the problem come when imap server goes down for whatever reason, apache reach the MaxClients Limit and never return to live by it self, i have to restart it by hand :-( today i was luck, i found this bug (because taroon message) and also my imap server goes down so i test the new php package and apache reach the MaxClient limits but, this time, it manage to survive and recover great from these imap server crash :-) big thanks to you Joe Orton!!! happiness will not be forever in the poor's house :-( my problem is still present :-( right now i got another imap server crash (two in one day, very uncommon but it happen) and the apache reach the limits and never come back from it, even when the imap server is back ... i don't know if i should enter a bug in bugzilla because maybe is a HORDE/IMP problem (but with apache-1.3.27-3.7.2 and php-4.1.2-7.2.6, same horde, same imap server i never had this problem), and also, i couldn't reproduce it making call to php pages in a "for" cicle. what do you think? sorry make you troble, i know this is not the rigth forum/way to ask An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-214.html Ok, I'm running RHEL AS 3 U3 and it upgraded the following packages: imap-2002d-9 and php-4.3.2-14.ent and php-imap-4.3.2-14.ent Yet I appear to get the same issue reported here. I haven't jumped through all of the hoops with the crash dumps etc... but I can state that the function imap_open function call is not working... not as documented by the PHP developers (http://us4.php.net/manual/en/function.imap-open.php) and not even with the added parameters that seemed to work with RHEL AS 3 U2 $mbox = @imap_open ("{localhost:143/imap/notls/user=" . $username ."}INBOX", "$username", "$password"); Any idea HOW to make this function work? I have several PHP scripts that are relying on the imap_open function for authentication... and not really to pick up email. Any work around, including a suggestion on a different function call to use... would be helpful. Scott, I think that should be /notls/norsh/, otherwise it will try to use rsh - that behaviour should not have changed since RHEL3 U2. Please file a separate bug if you're still having issues. Thanks, tacking on norsh/ to the end worked great! |