Bug 106796 - kmailcvt maxes out CPU and locks up on mbox import
Summary: kmailcvt maxes out CPU and locks up on mbox import
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: kmailcvt (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-04 21:30 UTC by Tristan Miller
Modified: 2009-03-19 00:30 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
The mbox I tried to import (131.76 KB, application/x-bzip2)
2005-06-04 21:32 UTC, Tristan Miller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tristan Miller 2005-06-04 21:30:36 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    SuSE RPMs

I tried to use the KMail import command to import a relatively small Unix mbox, copied directly from /var/mail on a Solaris system.  The file was 473K in size and had 157 messages.  The progress dialog got up to 99% and then stayed there.  CPU usage by kmailcvt was around 99%.  I let it run for about ten minutes of CPU time before finally aborting the process manually (the dialog window was frozen).  After aborting, I viewed the folder in KMail and everything seemed to be OK.
Comment 1 Tristan Miller 2005-06-04 21:32:55 UTC
Created attachment 11323 [details]
The mbox I tried to import

Here's the mbox I tried to import.  No privacy issues involved as except for
one message it's all spam.
Comment 2 Markus Brosch 2005-06-10 17:22:32 UTC
Same problem here. Some mbox'es get imported correctly, some hang at 99% and I have to kill kmailcvt. 
Comment 3 Danny Kukawka 2005-06-10 19:16:01 UTC
to #2: could you also send me a test mbox to reproduce?
Comment 4 Danny Kukawka 2005-06-21 17:57:17 UTC
The problem is: this is not a correct mbox. This file contain binary data between some of the messages ("^@" in vi/less ). But I think mbox should never contain binary data.

Because of this and a related  bug in qt  kmailcvt never reaches the end of file!
Comment 5 Danny Kukawka 2005-06-22 12:05:37 UTC
SVN commit 427894 by dkukawka:

- fixed problem with corrupted mbox, which contains binary data
  between mails. 
  The bug is related to a bug/problem in QT3 with QFile::readline() 
  and QFile::at() which returns wrong fileposition if the file contains 
  binary data 

BUG: 106796


 M  +10 -2     filter_mbox.cxx  


--- trunk/KDE/kdepim/kmailcvt/filter_mbox.cxx #427893:427894
@@ -68,8 +68,9 @@
 
             while ( ! mbox.atEnd() ) {
                 KTempFile tmp;
+                unsigned long filepos = 0;
                 /* comment by Danny:
-                * Don't use QTextStream to read from mbox, etter use QDataStream. QTextStream only 
+                * Don't use QTextStream to read from mbox, better use QDataStream. QTextStream only 
                 * support Unicode/Latin1/Locale. So you lost information from emails with 
                 * charset!=Unicode/Latin1/Locale (e.g. KOI8-R) and Content-Transfer-Encoding != base64 
                 * (e.g. 8Bit). It also not help to convert the QTextStream to Unicode. By this you
@@ -83,7 +84,14 @@
                 tmp.file()->writeBlock( input, l );
 
                 while ( ! mbox.atEnd() &&  (l = mbox.readLine(input.data(),MAX_LINE)) && ((seperate = input.data()).left(5) != "From ")) {
-                    tmp.file()->writeBlock( input, l );
+                       tmp.file()->writeBlock( input, l );
+                       
+                       // workaround to fix hang if a corrupted mbox contains some 
+                       // binary data, for more see bug #106796
+                       if (mbox.at() == filepos)
+                           mbox.at(mbox.size());
+                       else 
+                           filepos = mbox.at();
                 }
                 tmp.close();
                 first_msg = false;