evolution hangs on big multipart attachments

Thanks for your bug report. Can you install evolution-dbg and try to get a backtrace of the hang by running:

gdb -p $(pidof evolution)
...
* hang *
Ctrl-C
thread apply all bt

and copy the result into a comment.

Thanks for your quick response, i managed to produce the following result in gdb, also i noticed that the application takes up about 240mb of memory, i don't know if that is normal. If i don't use the debugger and wait too long, the system gets so unresponsive i have to reboot.

Thread 6 (Thread -1272853600 (LWP 17177)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7207321 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb72c2f1c in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.7
#3 0xb72c35e9 in e_msgport_reply () from /usr/lib/libedataserver-1.2.so.7
#4 0xb70a6504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb720e51e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 5 (Thread -1281246304 (LWP 17178)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7207321 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb72c2f1c in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.7
#3 0xb451ce7b in sync_op (emss=<value optimized out>,
    op=<value optimized out>, data=<value optimized out>, n=0)
    at em-sync-stream.c:229
#4 0xb451cff5 in stream_flush (stream=0x8280c58) at em-sync-stream.c:303
#5 0xb7400321 in camel_stream_flush () from /usr/lib/libcamel-1.2.so.8
#6 0xb4507a53 in efh_format_do (mm=0x8280c58) at em-format-html.c:1230
#7 0xb452c8c5 in mail_msg_received (e=0x80cf308, msg=0x824d730, data=0x0)
    at mail-mt.c:570
#8 0xb72c3594 in e_msgport_reply () from /usr/lib/libedataserver-1.2.so.7
#9 0xb70a6504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#10 0xb720e51e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 4 (Thread -1298068576 (LWP 17182)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7207321 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb72c2f1c in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.7
#3 0xb72c35e9 in e_msgport_reply () from /usr/lib/libedataserver-1.2.so.7
#4 0xb70a6504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb720e51e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (Thread -1289675872 (LWP 17188)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7207321 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb72c2f1c in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.7
#3 0xb72c35e9 in e_msgport_reply () from /usr/lib/libedataserver-1.2.so.7
#4 0xb70a6504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb720e51e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread -1342633056 (LWP 17189)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7207321 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb72c2f1c in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.7
#3 0xb72c35e9 in e_msgport_reply () from /usr/lib/libedataserver-1.2.so.7
---Type <return> to continue, or q <return> to quit---
#4 0xb70a6504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb720e51e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread -1232550224 (LWP 17171)):
#0 0xb7564b8a in html_object_calc_preferred_width ()
   from /usr/lib/libgtkhtml-3.8.so.15
#1 0xb75317cf in html_clue_type_init () from /usr/lib/libgtkhtml-3.8...

This looks like a gtkhtml3.8 problem. Can you attach a message that is causing problems? Also can you try to get another backtrace with libgtkhtml3.8-dbg installed?

Here is the new backtrace with libgtkhtml3.8-dbg.

Thread 7 (Thread -1273779296 (LWP 5513)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7128321 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb71e3f1c in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.7
#3 0xb71e45e9 in e_msgport_reply () from /usr/lib/libedataserver-1.2.so.7
#4 0xb6fc7504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb712f51e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 6 (Thread -1282172000 (LWP 5514)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb711fb6b in read () from /lib/tls/i686/cmov/libc.so.6
#2 0xb72fd51f in camel_read () from /usr/lib/libcamel-1.2.so.8
#3 0xb72f9145 in camel_block_file_get_block () from /usr/lib/libcamel-1.2.so.8
#4 0xb731c9de in camel_key_table_lookup () from /usr/lib/libcamel-1.2.so.8
#5 0xb7323bd1 in camel_text_index_new () from /usr/lib/libcamel-1.2.so.8
#6 0xb74e0856 in g_hash_table_foreach () from /usr/lib/libglib-2.0.so.0
#7 0xb73238f9 in camel_text_index_new () from /usr/lib/libcamel-1.2.so.8
#8 0xb72ff32a in camel_index_write_name () from /usr/lib/libcamel-1.2.so.8
#9 0xb73504ba in camel_folder_summary_info_new_from_message ()
   from /usr/lib/libcamel-provider-1.2.so.8
#10 0xb7350e2c in camel_folder_summary_add_from_message ()
   from /usr/lib/libcamel-provider-1.2.so.8
---Type <return> to continue, or q <return> to quit---
#11 0xb41437b6 in camel_local_summary_get_type ()
   from /usr/lib/evolution-data-server-1.2/camel-providers-8/libcamellocal.so
#12 0xb41484fa in camel_mbox_summary_new ()
   from /usr/lib/evolution-data-server-1.2/camel-providers-8/libcamellocal.so
#13 0xb41430f1 in camel_local_summary_add ()
   from /usr/lib/evolution-data-server-1.2/camel-providers-8/libcamellocal.so
#14 0xb4144c88 in camel_mbox_folder_new ()
   from /usr/lib/evolution-data-server-1.2/camel-providers-8/libcamellocal.so
#15 0xb7355b4c in camel_folder_append_message ()
   from /usr/lib/libcamel-provider-1.2.so.8
#16 0xb734712f in camel_filter_driver_filter_message ()
   from /usr/lib/libcamel-provider-1.2.so.8
#17 0xb734786f in camel_filter_driver_filter_folder ()
   from /usr/lib/libcamel-provider-1.2.so.8
#18 0xb444f366 in em_filter_folder_element_filter (mm=0x8233888)
    at mail-ops.c:140
#19 0xb444f667 in fetch_mail_fetch (mm=0x8233888) at mail-ops.c:325
#20 0xb444a8c5 in mail_msg_received (e=0x81af720, msg=0x8233888, data=0x0)
    at mail-mt.c:570
#21 0xb71e4594 in e_msgport_reply () from /usr/lib/libedataserver-1.2.so.7
#22 0xb6fc7504 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#23 0xb712f51e in clone () from /lib/tls/i686/cmov/libc.so.6

---Type <return> to continue, or q <return> to quit---
Thread 5 (Thread -1290601568 (LWP 5518)):
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7128321 in select () from /lib/tls/i686/cmov/libc.so.6
#2 0xb71e3f1c in e_msgport_wait () from /usr/lib/libedataserver-1.2.so.7
#3 0xb443ae7b in sync_op (emss=<value optimized out>,
    op=<value optimized out>, data=<value optimized out>, n=0)
    at em-sync-stream.c:229
#4 0xb443aff5 in stream_flush (stream=0x86c0d98) at em-sync-stream.c:303
#5 0xb7321321 in camel_stream_flush () from /usr/lib/li...

I found a matching upstream report at: http://bugzilla.gnome.org/show_bug.cgi?id=350394

Do you get that attachment displayed inline or as an attachment? If it's trying to render 10M of data that would explain it hangs like that

Yes it is displayed inline as if it is text (while in fact it is an attachment). Of course this explains the behaviour of the application, but right now if somebody in the world sends me a message like that it means i can't use evolution anymore. I don't think this is desired behaviour.

the bug should be fixed in the recent versions, closing it now, you can reopen if you still get the issue though

I'm having the same problem currently. I received an email with a 16mb multi-part attachment. Evolution hangs when loading it. The problem is, when I open evolution that's the first thing the evolution tries to display. I had to move the mail somewhere other than the inbox using gmail's webmail.

I can reproduce this as well. Today I received a mail with 20mb attachment and evolution hanged for ever while showing "Formatting message". This is quite annoying.