Opened 7 years ago

Closed 5 years ago

#1484438 closed Bugs (fixed)

Infinite "loading" loop on display of some emails

Reported by: godot Owned by: till
Priority: 5 Milestone: 0.2-stable
Component: IMAP connection Version: 0.1-rc1
Severity: normal Keywords:
Cc:

Description

I'm working to isolate the root cause of this issue; but didn't see a ticket opened on it. There are some emails that simply loop forever (read or unread) and do not display. I have not yet found a workaround. Forwarding the emails to myself (with another client) allows them to be read.

Is there any script I can run on said emails to assist in determining the cause?

Attachments (3)

imap.inc.patch (1.3 KB) - added by bbt 6 years ago.
sample.mail (349 bytes) - added by bbt 6 years ago.
sample-loadingerror-message.txt (4.7 KB) - added by smultron 5 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by till

  • Owner set to till
  • Status changed from new to assigned

You can enable logging and check logs/error to see a course. I guess it's not looping for forever, rather probably dies in the background and the JavaScript? doesn't hide the "loading".

To me this sounds like a configuration issue - max_execution_time, memory_limit etc..

Please provide more feedback.

comment:2 Changed 7 years ago by thomasb

  • Milestone changed from 0.1-rc2 to 0.1-stable

Not a show stopper.

Changed 6 years ago by bbt

comment:3 Changed 6 years ago by bbt

I can reproduce this on a debian system (Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7) but not on freebsd (Apache/2.2.6 (FreeBSD) mod_ssl/2.2.6 OpenSSL/0.9.7e-p1 DAV/2 PHP/5.2.5).

The problem is in the imap.inc file:
Function iil_ReadLine catches an error and returns, but function iil_C_HandlePartBody doesn't know about the error and goes on looping forever.

I have created a patch which cuts the loop but doesn't resolve the underlying problem...

I can also upload a sample mail causing the problem

comment:4 Changed 6 years ago by till

@bbt I am reviewing your patch and if you can, please upload an email too.

comment:5 Changed 6 years ago by till

  • Priority changed from 3 to 5
  • Resolution set to worksforme
  • Status changed from assigned to closed

Reviewing this again, there seems to be a couple weird things.

I am not sure why the buffersize is hardcoded in iil_ReadLine() etc. (see [a527781d]). I am not really committing parts of this patch before I get an email to reproduce this.

Until then, WORKSFORME. So if anyone wants to see progress - please contribute.

On a side note, since the ticket is pretty old (and so is the patch), I just hope this is fixed already.

comment:6 Changed 6 years ago by bbt

I am no longer able to reproduce this with the sample mail I have (iil_ReadLine() doesn't catch any error), so it may have been something misconfigured in php at my side, sorry. I'll upload the mail anyway.

In any case, you can "force" a similar error in iil_ReadLine() by commenting the if ($buffer === false) line, and whenever there is a call to the function from within a loop it will go on forever.

If you think this is not an error (because fgets() should *never* return false), you can leave this ticket closed, but IMHO any loop should check for errors while calling this function.

Changed 6 years ago by bbt

comment:7 follow-up: Changed 5 years ago by smultron

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I'm still experiencing this issue with the SVN 2009 (also tried with 2046). Certain messages loop forever on "Loading..." until it times-out. I'll attached a sample message which causes this to happen (munged but essentially the same). Let me know if I can provide any more info to help. I'm on OS X Server 10.5.

./log/error: [12-Nov-2008 05:15:31] PHP Fatal error: Maximum execution time of 120 seconds exceeded in /Library/WebServer/Webmail?/program/lib/imap.inc on line 227

Here's the corresponding part of imap.inc:

220 function iil_ReadLine($fp, $size) {
221 $line = ;
222
223 if (!$fp) {
224 return $line;
225 }
226
227 if (!$size) {
228 $size = 1024;
229 }
230
231 do {
232 $buffer = fgets($fp, $size);
233 if ($buffer === false) {
234 break;
235 }
236 console('S: '. chop($buffer));
237 $line .= $buffer;
238 } while ($buffer[strlen($buffer)-1] != "\n");

Changed 5 years ago by smultron

comment:8 in reply to: ↑ 7 Changed 5 years ago by smultron

Sorry, last part was supposed to look like this:

 220 function iil_ReadLine($fp, $size) {
 221         $line = '';
 222 
 223         if (!$fp) {
 224                 return $line;
 225         }
 226 
 227         if (!$size) {
 228                 $size = 1024;
 229         }
 230 
 231         do {
 232                 $buffer = fgets($fp, $size);
 233                 if ($buffer === false) {
 234                         break;
 235                 }
 236 //              console('S: '. chop($buffer));
 237                 $line .= $buffer;
 238         } while ($buffer[strlen($buffer)-1] != "\n");

comment:9 Changed 5 years ago by alec

  • Component changed from Client Scripts to MIME parsing
  • Milestone changed from 0.1-stable to 0.2-stable

Last part of attached message is malformed and message isn't displayed in roundcube without errors in log.

comment:10 Changed 5 years ago by alec

  • Component changed from MIME parsing to IMAP connection
  • Resolution set to fixed
  • Status changed from reopened to closed

Fixed in [ceb52fe0].

Note: See TracTickets for help on using tickets.