ID: 17724 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: IMAP related Operating System: IRIX 6.5.16F / IP25 PHP Version: 4.2.1 New Comment:
Debian Woody Current Now.... this bug DOES appear in php4.2.1...havent tested it in other version because it appears in a production deployment of phpgroupware. This will not show in squirrelmail since it (very smartly) does not trust php-imap. The bug ONLY presents itself with heavy load, im talking 1,000,000<hits<100,000 (which is what im testing against). Ive played it with athlon machines, intel pproIV machines, have seen it in production and have only be able to reproduce it with batch tests (400 concurrent users, which mimics my production environment) using eliza scripts. The result is hung apache proceses that take up 100% of tyhe available cpu. I can divide this bug in two parts: 1.- php-imap logs an error to apache and says something about having hit its limit. I have never seen this in production, only in the lab tests. 2.- No error, no logs, no nothing....apache just goes away and away. This is a critical bug....:(... hard to reproduce but important for bigger sites, DONT overlook it please. Previous Comments: ------------------------------------------------------------------------ [2002-07-27 01:00:07] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2002-06-26 20:51:07] [EMAIL PROTECTED] And did you get that backtrace with the latest CVS snapshot of PHP? This one: http://snaps.php.net/php4-latest.tar.gz ------------------------------------------------------------------------ [2002-06-26 20:49:59] [EMAIL PROTECTED] I can not reproduce this..are you able to reproduce this with some specific script? It does look like some problem in c-client still. Are you sure the imap server is not dying there? Can you access it's logs? That imap_list_work() line looks a bit odd, this is what I got when I debugged this: imap_list_work (stream=0x84a77c0, cmd=0x838bf34 "LSUB", ref=0x84a2734 "{mail.kolumbus.fi:143}", pat=0x84a8434 "*", contents=0x0) ------------------------------------------------------------------------ [2002-06-16 05:00:33] [EMAIL PROTECTED] Ok, finally got a good one I think, there's a 0x0 ptr in zif_imap_lsub, i'm not sure if that's normal or not, but I wouldn't think a null pointer ever is. There's definitely a problem somewhere in memory allocation/reference here, you would know better than I if this is definitely in imap's c-client or the php imap module. (gdb) bt #0 0x10286034 in imap_valid (name=Cannot access memory at address 0x7ffe3d34 ) at imap4r1.c:113 #1 0x10286590 in imap_list_work (stream=0x0, cmd=0x0, ref=0x7ffe4f68 "", pat=0x1030ddd9 "|l", contents=0x0) at imap4r1.c:280 #2 0x102863fc in imap_lsub (stream=0x10494ac0, ref=0x0, pat=0x0) at imap4r1.c:248 #3 0x10262494 in mail_lsub (stream=0x101b11b4, ref=0xa <Address 0xa out of bounds>, pat=0x1 <Address 0x1 out of bounds>) at mail.c:754 #4 0x101b14d4 in zif_imap_lsub (ht=3, return_value=0x104d4c50, this_ptr=0x0, return_value_used=1) at php_imap.c:1706 #5 0x101193a0 in execute (op_array=0x1053c220) at zend_execute.c:1598 #6 0x10119608 in execute (op_array=0x104ca0f8) at zend_execute.c:1638 #7 0x10119608 in execute (op_array=0x106921e8) at zend_execute.c:1638 #8 0x10119608 in execute (op_array=0x104cd3f0) at zend_execute.c:1638 #9 0x1011bc14 in execute (op_array=0x105192d8) at zend_execute.c:2141 #10 0x1011bc14 in execute (op_array=0x105532c8) at zend_execute.c:2141 #11 0x10077368 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810 #12 0x10065934 in php_execute_script (primary_file=0x7fff28f8) at main.c:1381 #13 0x101128ac in apache_php_module_main (r=0x10462cc8, display_source_mode=0) at sapi_apache.c:90 Cannot access memory at address 0x7fff2a24 ------------------------------------------------------------------------ [2002-06-13 20:32:51] [EMAIL PROTECTED] 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. the above should have information where to find more information..(okay, I'm lazy :) ------------------------------------------------------------------------ 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/17724 -- Edit this bug report at http://bugs.php.net/?id=17724&edit=1
