Summary: | Kmail crash with iso-2022-jp, libkhtml related | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | Francois Cartegnie <bugzilla77> |
Component: | GUI | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | crash | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Francois Cartegnie
2006-04-29 08:16:04 UTC
How can we reproduce this problem? I can send a dump of the offensive content from the mailbox. You'll can easily isolate the code. It seems that's when iso-2022-jp produce a "<" as starting bit for a character. The lib seems to look the only 1st byte and open a tag. Where should I send content ? The reporter sent me the offending email in a private email. I cannot reproduce the crash. All three emails in the mailbox open perfectly in KMail 1.9.2 r529439 Perhaps it's the Xft problem as in bug 121382? Does downgrading libXft help? 2 ways of crashing, I reproduce everyday :(: Reply to an iso-2022-jp mail, quoting adresses aa <aa@aa.com> Send it as iso-2022-jp (needs to be forced as kmail in french selects utf8 for the quoting tag special chars) Check it in your sent box -> crash Receive a quoted (again with adresses) reply to your iso-2022-jp -> crash Solving needs to open mailbox with hex editor and suppress any "<" from quoted sender/destination adresses. Thus kmails looses its index after modification :( My distro is already on libXft 2.1.2, so this is not the origin of the problem. Changing iso-2022-jp to iso-8859-1 with hexadecimal editor solves the problem too. Seems that's a 2-byte processing segfault from an html processing. Do you still see the problem in KDE 3.5? If so, please attach a message that shows the problem Feedback timeout, but please reopen if the problem still occurs in KDE 3.5. Thanks! |