From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 Description of problem: The following little script works fine when run from the cli: <html> <body> <? $mbox =imap_open('{imap.hio.no/notls/norsh}INBOX.Trash','user','secret') or die("Could not connect to imap server"); echo $mbox,"\n"; imap_close($mbox); ?> </body> </html> A typical output: # php imap.php Content-type: text/html X-Powered-By: PHP/4.3.2 <html> <body> Resource id #1 </body> </html> If the script is served through apache there is no output, and no entry in the access-log. In the error-log there is the following: [Fri Mar 12 13:41:59 2004] [notice] child pid 1972 exit signal Segmentation fault (11) Some testing shows that this does not occur when the imap server allows plaintext logins, CRAM-MD5 seems to be the problem. Sniffing with ethereal shows that the script starts the imap connection and then dies before completing the login. I am not sure if this is a php, httpd og imap-2002d problem. Version-Release number of selected component (if applicable): php-4.3.2-8.ent How reproducible: Always Steps to Reproduce: 1. Use imap_open from php against imap server that does not allow plaintext logins 2. The script dies 3. Actual Results: Nothing apart from entries in the error log. Expected Results: At least some output in my browser. Additional info:
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!