| Summary: | Corrupt indicies can make KMail allocate way too much memory (and crash) | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | Malte S. Stretz <mss> |
| Component: | general | Assignee: | kdepim bugs <pim-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | crash | CC: | sanskryt |
| Priority: | NOR | ||
| Version First Reported In: | SVN (3.5 branch) | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Malte S. Stretz
2004-05-29 18:25:03 UTC
Wow. The Magic Dup FInder tells me that this crash already happened almost half a year ago. It's bug 70406. Even after I removed all (root) indicies, it still crashes. Finally... got the problem. It seems like I've got one corrupted index lying around which makes KMMsgDict::readFolderIds() create a new KMMsgDictREntry with 1296769059 elements. Which can't be allocated. But as the return value of array.resize(size) in the ctor isn't checked, KMail tries anyways. The size should probably limited to a reasonable size anyway to avoid stuff like bug 82455. If the real reason for this big number isn't corruption (to get where it creates the entry it has to pass a few sanity checks), maybe that weird swapByteOrder macro (called in KMMsgDict::readFolderIds) is borked? If wanted, I can attach both the folder (it's an mbox, my virus collection ;) and the indicies. I also noticed that KMFolderMgr::readMsgDict doesn't check the return value of KMMsgDict::readFolderIds though that one can fail. *** Bug 82455 has been marked as a duplicate of this bug. *** *** Bug 80410 has been marked as a duplicate of this bug. *** |