Bug 126450 - Kmail crash with iso-2022-jp, libkhtml related
Summary: Kmail crash with iso-2022-jp, libkhtml related
Status: RESOLVED WORKSFORME
Alias: None
Product: kmail
Classification: Applications
Component: GUI (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR crash
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-29 08:16 UTC by Francois Cartegnie
Modified: 2007-09-14 12:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francois Cartegnie 2006-04-29 08:16:04 UTC
Version:           inconnu (using KDE 3.4.2, Mandrake Linux Cooker i586 - Cooker)
Compiler:          Target: i586-mandriva-linux-gnu
OS:                Linux (i686) release 2.6.14-2mdk

Kmail crashes with some iso-2022-jp mail.

related to closed bug 24220

#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb700def1 in raise () from /lib/tls/libc.so.6
#2  0xb700f83b in abort () from /lib/tls/libc.so.6
#3  0xb7043ff5 in __fsetlocking () from /lib/tls/libc.so.6
#4  0xb704a07c in malloc_usable_size () from /lib/tls/libc.so.6
#5  0xb704af20 in free () from /lib/tls/libc.so.6
#6  0xb704c6ef in malloc () from /lib/tls/libc.so.6
#7  0xb5eae4ae in XftFontOpenInfo () from /usr/X11R6/lib/libXft.so.2
#8  0xb5eaf4fa in XftFontOpenPattern () from /usr/X11R6/lib/libXft.so.2
#9  0xb741c72e in QFontDatabase::styleString ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#10 0xb7422978 in QFontDatabase::findFont ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#11 0xb73af002 in QFontPrivate::load () from /usr/lib/qt3/lib/libqt-mt.so.3
#12 0xb73af5a3 in QFontMetrics::charWidth ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#13 0xb6e6ac6e in non-virtual thunk to KHTMLPart::~KHTMLPart() ()
   from /usr/lib/libkhtml.so.4
#14 0x0882b614 in ?? ()
#15 0xbfc775b4 in ?? ()
#16 0x00000005 in ?? ()
#17 0xb6fc804c in ?? () from /usr/lib/libkhtml.so.4
#18 0x0882c6d8 in ?? ()
#19 0x088339c8 in ?? ()
#20 0x0000001e in ?? ()
#21 0xb6fc804c in ?? () from /usr/lib/libkhtml.so.4
#22 0x08829550 in ?? ()
#23 0x00000000 in ?? ()

registers:
eax            0x0      0
ecx            0x1275   4725
edx            0x6      6
ebx            0x1275   4725
esp            0xbfc76cc0       0xbfc76cc0
ebp            0xbfc76cd8       0xbfc76cd8
esi            0x0      0
edi            0xb710fff4       -1223622668
eip            0xffffe410       0xffffe410
eflags         0x200202 2097666
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
Comment 1 Thiago Macieira 2006-05-02 20:06:55 UTC
How can we reproduce this problem?
Comment 2 Francois Cartegnie 2006-05-03 10:21:50 UTC
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 ?
Comment 3 Thiago Macieira 2006-05-03 13:21:54 UTC
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
Comment 4 Philip Rodrigues 2006-09-19 23:56:12 UTC
Perhaps it's the Xft problem as in bug 121382? Does downgrading libXft help?
Comment 5 Francois Cartegnie 2006-10-16 04:03:22 UTC
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 :(


Comment 6 Francois Cartegnie 2006-10-17 03:54:53 UTC
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.
Comment 7 Philip Rodrigues 2007-01-29 23:10:57 UTC
Do you still see the problem in KDE 3.5? If so, please attach a message that shows the problem
Comment 8 Philip Rodrigues 2007-06-04 00:19:35 UTC
Feedback timeout, but please reopen if the problem still occurs in KDE 3.5. Thanks!