GNOME Bugzilla – Bug 463430
Gets stuck while "formatting message"
Last modified: 2007-11-05 18:35:17 UTC
Please describe the problem: When I select a specific message coming from a known provider, the program tries to preview it, with no result. It remains stuck, with a "formatting message" info at the bottom and no part of Evolution can be used any more. If I ask for Gnome System Monitor, it appears that one of the two CPU's is totally taken by the process (100% usage). After 1h it was still stuck. On the contrary, there is no apparent HD usage. The problem is that if I forcedly close Evolution, while opening it again, it reverts to the same message, with no possibility of exiting the deadlock. Just out of curiosity, I tried watching the mail with Balsa client, and it got stuck the same way on the same message!! Steps to reproduce: 1. Try opening the same e-mail message. I can forward it to you. 2. 3. Actual results: See description Expected results: Well, nothing. That the e-mail can be sees, or at least deleted Does this happen every time? Yes, absolutely, with any version of Evolution I have tried, and with Balsa too. Other information:
when it happens with balsa too, it's most probably not an evolution bug ;-) how big is that message? if you set edit->preferences->mail preferences->message display to not display mail bigger than 2mb, does it display?
I agree that probably it's not an Evolution-specific issue. The problem is that Evolution gets stuck on that message immediately after I start it, so I have no chance of accessing menus, and changing display options. I should change them before entering the program, from a command line, or a configuration file, because as soon as I start the program, it freezes. Offending message size is 95 kb. For your information, MS-Outlook Express opens it, but has a very strange behaviour, because it prints several pages of this stuff: "Precedence: list Precedence: list Precedence: list Precedence: list Precedence: list Precedence: list Precedence: list Precedence: list Precedence: list..." and, in the end, the content of the message. Thanks for your help. Best regards
Can you attach the email here. Feel free to mask out the sensitive portions in the email. That would be helpful for fixing it.
Created attachment 93438 [details] Offending e-mail message as downloaded by MS-Outlook on an XP machine
It stuck in pango_shape with one long line (79186 characters long). It should be fixed there. Btw, thanks for data, I like bugs with data, because it's (often) easier to reproduce. :)
Created attachment 93717 [details] [review] proposed pango patch
Changing component to Pango for Behdad to have a look.
Which font does this happen with? Can someone attach the actual text of the message, copy/pasted from inside outlook?
Comment on attachment 93717 [details] [review] proposed pango patch >Index: pango/opentype/harfbuzz-gpos.c >=================================================================== >--- pango/opentype/harfbuzz-gpos.c (revision 2400) >+++ pango/opentype/harfbuzz-gpos.c (working copy) >@@ -6121,9 +6121,14 @@ > } > > if ( error == HB_Err_Not_Covered ) >+ { > (buffer->in_pos)++; >+ } > else >+ { > retError = error; >+ break; >+ } > } > return retError; The patch is incorrect. If error==FT_Err_Ok is returned, means that buffer->in_pos is advanced by the applied lookup. There is a bug somewhere else that the particular font and text combination hits.
Created attachment 94037 [details] same email as above, but now as mbox, easy to import in evolution OK, maybe the approach should be different, but one thing is obvious, when you didn't increment buffer->in_pos, then you should stop, otherwise you come into infinite loop, which happened here. Try import and preview/see this email. (It's better to turn off preview pane, so you will be able to run evo next time, and double click on an email.)
(In reply to comment #10) > OK, maybe the approach should be different, but one thing is obvious, when you > didn't increment buffer->in_pos, then you should stop, otherwise you come into > infinite loop, which happened here. As I said, buffer->in_pos may be increased outside the current function. That's what's expected to happen.
I don't know pango, I just found where it stuck and how I could "easily" "fix" it, and it seemed to me it worked. Please fix this in a proper way, so it will work as expected. Thanks in advance. :)
Created attachment 94038 [details] [review] patch The bug was a FT_Short index variable overflowing because the input text was longer than 65536 glyphs.
2007-08-21 Behdad Esfahbod <behdad@gnome.org> Bug 463430 – Gets stuck while "formatting message" * pango/opentype/harfbuzz-gpos.c (Lookup_PairPos1), (Lookup_PairPos2), (Lookup_PairPos), (Do_ContextPos): * pango/opentype/harfbuzz-gsub.c (Do_ContextSubst): Change type of intermediate index variable from FT_UShort to FT_ULong as it was overlowing with more than 65536 glyphs.
Hi, does this patch have any security implication? Thanks,
You can call it DoS. If an email or webpage has a string longer than about 64k, it can put the firefox/evolution process into an infinite loop, essentially hanging it, possibly causing data loss.
I have just experienced "formatting message" forever again. My pango contains ChangeLog with upper mentioned fix. Note that it might be a problem of other part of code, because this message works OK after killing evolution. OpenSUSE 10.3 with: pango-1.18.2 glib-2.14.1 gtk+-2.12.0 gtkhtml2-3.16.0-3 evolution-2.12.0 evolution-data-server-1.12.0 Backtrace shows nothing interesting:
+ Trace 175415
(In reply to comment #17) > I have just experienced "formatting message" forever again. My pango contains > ChangeLog with upper mentioned fix. > > Note that it might be a problem of other part of code, because this message > works OK after killing evolution. > > OpenSUSE 10.3 with: > > pango-1.18.2 > glib-2.14.1 > gtk+-2.12.0 > gtkhtml2-3.16.0-3 > evolution-2.12.0 > evolution-data-server-1.12.0 > > Backtrace shows nothing interesting: > #0 0x00002b055db399e6 in poll () from /lib64/libc.so.6 > #1 0x00002b055d7e71c7 in g_main_context_iterate () from > /usr/lib64/libglib-2.0.so.0 > #2 0x00002b055d7e7657 in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0 > #3 0x00002b05581f03a6 in bonobo_main () from /usr/lib64/libbonobo-2.so.0 > #4 0x000000000041678a in main (argc=<value optimized out>, > argv=0x7fff5ab0b938) at main.c:602 > #5 0x00002b055da9ab54 in __libc_start_main () from /lib64/libc.so.6 > #6 0x000000000040ac39 in _start () Well it does, and it's that it has nothing to do with pango or this bug.