Bug 161544

Summary: Kmail eats all memory and crashes
Product: [Unmaintained] kmail Reporter: envite
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED WORKSFORME    
Severity: normal CC: christophe, finex, kusi, smartins, zahl
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: valgrind log

Description envite 2008-05-03 01:39:22 UTC 
Version:            (using KDE 3.5.9)
Installed from:    Debian testing/unstable Packages

I have 5 accounts in Kmail. 4 POP and 1 IMAP. One of the POP is disabled, and the other four accounts are set up in such a way that they always ask for password.

Since upgrading to Debian version 4:3.5.9-2 (Sorry, I do no tremember the previous version) I have the following problem:

When I start Kmail it behaves correctly and asks me for the four passwords. Even if I do not give them, the applications starts correctly. It just do not check for messages in the servers.

Then, when I click on _any_ folder with messages, Kmail hags, starts eating all available memory (confirmed by top and similar apps) and CPU goes 100% accessing disk (kernel 2.6.24) and when no more memory (RAM nor swap) is available the application dies. No backtrace available:

"
Esta traza inversa parece inútil.
Probablemente se deba a que sus paquetes están generados de forma que eviten la creación de trazas inversas adecuados, o la pila se ha corrompido seriamente durante el fallo de la aplicación.

(no debugging symbols found)
Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
"

I repeat: the problem is NOT downloading e-mail from the server, but just accessing a local folder in which e-mail is stored.

du shows that the _total_ size of my .kde/share/apps/kmail subdirectory is less than half a GiB, and Kmail crashes even if I give it more than ten times that space in available Swap.

...And I do not want to change to any other e-mail client. I love my maildir folders, since I do not trust mbox.
Comment 1 envite 2008-05-03 01:52:59 UTC 
korgac behaves the same way, thus maybe the problem is not specific of Kmail but of the whole KDE:

"
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
KCrash: Application 'korgac' crashing...

[1]+  Exit 255                korgac
"
Comment 3 _r1_ 2008-07-12 17:43:45 UTC 
I confirm exactly same bug with 5 pop account.
Comment 4 _r1_ 2008-07-12 18:30:40 UTC 
Created attachment 26059 [details]
valgrind log
Comment 5 Kusi 2008-09-01 21:30:51 UTC 
I can confirm this bug with kaddressbook, korgac and kmail, using kde 3.5.9. It eats all my memory (4gig) and sometimes crash, sometimes makes the system unusable. It used to work all fine a while ago
Comment 6 FiNeX 2008-11-19 20:25:19 UTC 
Changed severity to "crash". I hope to have selected only the right bugs (>100) :-)
Comment 7 A. Spehr 2009-04-04 14:39:13 UTC 
comment 4 inline paste of what i think is the backtrace portion of the valgrind log:

==19050== Warning: set address range perms: large range 402653216 (noaccess)
**19050** new/new[] failed and should throw an exception, but Valgrind
   cannot throw exceptions and so is aborting instead.  Sorry.
==19050==    at 0x4022D34: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==19050==    by 0x4022F81: operator new[](unsigned) (vg_replace_malloc.c:268)
==19050==    by 0x60E9AA8: QString::setLength(unsigned) (in /usr/lib/libqt-mt.so.3.3.8)
==19050==    by 0x60E9C1D: QString::grow(unsigned) (in /usr/lib/libqt-mt.so.3.3.8)
==19050==    by 0x60EB16D: QString::operator+=(QString const&) (in /usr/lib/libqt-mt.so.3.3.8)
==19050==    by 0x60FF203: QTextStream::read() (in /usr/lib/libqt-mt.so.3.3.8)
==19050==    by 0x510C733: KABC::VCardFormatPlugin::loadAll(KABC::AddressBook*, KABC::Resource*, QFile*) (in /usr/lib/libkabc.so.1.2.0)
==19050==    by 0x80438D6: KABC::ResourceFile::load() (in /usr/lib/libkabc_file.so.1.0.0)
==19050==    by 0x80435F8: KABC::ResourceFile::asyncLoad() (in /usr/lib/libkabc_file.so.1.0.0)
==19050==    by 0x50E6CEA: KABC::AddressBook::asyncLoad() (in /usr/lib/libkabc.so.1.2.0)
==19050==    by 0x50E73CB: KABC::StdAddressBook::init(bool) (in /usr/lib/libkabc.so.1.2.0)
==19050==    by 0x50E754F: KABC::StdAddressBook::StdAddressBook(bool) (in /usr/lib/libkabc.so.1.2.0)
==19050== 

And the final leak report:
==19050== LEAK SUMMARY:
==19050==    definitely lost: 51,172 bytes in 1,681 blocks.
==19050==      possibly lost: 5,524 bytes in 6 blocks.
==19050==    still reachable: 540,936,605 bytes in 108,617 blocks.
==19050==         suppressed: 0 bytes in 0 blocks.
Comment 8 A. Spehr 2009-04-04 14:41:13 UTC 
But new/new[] makes it sound like the above leak report is misleading.
Comment 9 Sergio Martins 2013-07-18 08:50:05 UTC 
closing this pre-akonadi bug report