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.
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 "
I run strace on Kmail. I can not e-mail the files (too big) but I've posted them in the following URLs: http://www.rolamasao.org/kmail.strace.8175 http://www.rolamasao.org/kmail.strace.8182 http://www.rolamasao.org/kmail.strace.8190 http://www.rolamasao.org/kmail.strace.8191 http://www.rolamasao.org/kmail.strace.8192 http://www.rolamasao.org/kmail.strace.8193
I confirm exactly same bug with 5 pop account.
Created attachment 26059 [details] valgrind log
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
Changed severity to "crash". I hope to have selected only the right bugs (>100) :-)
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.
But new/new[] makes it sound like the above leak report is misleading.
closing this pre-akonadi bug report