GNOME Bugzilla – Bug 704181
Froze while filtering messages
Last modified: 2013-08-09 15:45:37 UTC
evolution-3.8.3-2.fc19.i686 froze while just scrolling through the message list of my IMAP+ account. gdb -p 123 output: Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib/libgobject-2.0.so.0.3600.3-gdb.py", line 9, in <module> from gobject import register File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module> import gdb.backtrace ImportError: No module named backtrace (gdb) thread apply all bt
+ Trace 232237
(gdb) list 428 429 g_object_unref (settings); 430 431 return shell; 432 } 433 434 gint 435 main (gint argc, 436 gchar **argv) 437 { (gdb) info registers eax 0xfffffe00 -512 ecx 0x80 128 edx 0x1 1 ebx 0xc4c04e4 206308580 esp 0xbfebb428 0xbfebb428 ebp 0x1 0x1 esi 0x0 0 edi 0x8cdec30 147713072 eip 0xb77c2424 0xb77c2424 <__kernel_vsyscall+16> eflags 0x200206 [ PF IF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51
Filtering actions still block the UI. Major rewrite needed.
*** Bug 704231 has been marked as a duplicate of this bug. ***
...which triggers gnome-shell's “Inbox (26 unread, 1970 total) - Evolution” is not responding. You may choose to wait a short while for it to continue or force the application to quit entirely. a few times every day for me. So much for gnome-shell not being disruptive, to "do your work". ;)
Created attachment 249548 [details] [review] eds patch for evolution-data-server; An "interim" solution. I do not think it's a fault of the CamelFolder, it's rather a fault of the imapx, and some other consecutive changes, like the job scheduler, calling free function in the main thread, instead of a dedicated thread.
Created commit 2524e6b in eds master (3.9.5+) Created commit 8bbf459 in eds gnome-3-8 (3.8.4+)
(In reply to comment #4) > An "interim" solution. I do not think it's a fault of the CamelFolder, it's > rather a fault of the imapx, and some other consecutive changes, like the job > scheduler, calling free function in the main thread, instead of a dedicated > thread. It's the fault of CamelFilterDriver for blocking in its finalize() method. finalize() methods should never ever block.
Thanks a lot; looking forward to the package update in F19.
*** Bug 700850 has been marked as a duplicate of this bug. ***