GNOME Bugzilla – Bug 655248
chew of CPU and X server ...
Last modified: 2014-12-02 01:05:15 UTC
With some mails - I get an horrific interaction as I preview them in the mail pane. The X server and Evo fight each other in an endless loop. It seems this comes down to a couple of hundred calls to gtk_container_queue_resize each second [!] ;-) which is triggered from: gtkcontainer.c (_gtk_container_queue_resize_internal) which in turn is called from: html_engine_update_event at htmlengine.c:4845 will paste a better trace from the separate debugging machine. Needless to say the UI is not visibly changing at all - so all this re-laying-out is just wasted work. Luckily Evo. stays responsive - it is after all an idle effect - and is still usable: although the machine gets horribly sluggish with all this extra work.
(gdb) bt
+ Trace 227873
... 4751 static void 4752 update_embedded (GtkWidget *widget, gpointer data) 4753 { 4754 HTMLObject *obj; 4755 4756 /* FIXME: this is a hack to update all the embedded widgets when 4757 * they get moved off screen it isn't gracefull, but it should be a effective 4758 * it also duplicates the draw_obj function in the drawqueue function very closely 4759 * the common code in these functions should be merged and removed, but until then (gdb) 4760 * enjoy having your objects out of the way :) 4761 */ 4770 html_object_engine_translation (obj, NULL, &x, &y); 4771 4772 x += obj->x; 4773 y += obj->y - obj->ascent; 4774 4775 if (!gtk_widget_get_parent (emb->widget)) { 4776 gtk_layout_put (GTK_LAYOUT (emb->parent), emb->widget, x, y); 4777 } else { 4778 gtk_layout_move (GTK_LAYOUT (emb->parent), emb->widget, x, y); We loop from this layout_move: (gdb) p x $1 = 6 (gdb) p y $2 = 120 (gdb) p emb->widget $3 = 0x974f350 (gdb) p *emb->widget $4 = {parent_instance = {g_type_instance = {g_class = 0x986b900}, ref_count = 1, qdata = 0x98d2f80}, priv = 0x974f390} (gdb) p *emb->widget->priv $5 = {state_flags = 0, direction = 0, in_destruction = 0, toplevel = 0, anchored = 1, composite_child = 0, no_window = 1, realized = 1, mapped = 1, visible = 1, sensitive = 1, can_focus = 0, has_focus = 0, can_default = 0, has_default = 0, receives_default = 0, has_grab = 0, shadowed = 0, rc_style = 0, style_update_pending = 1, app_paintable = 0, double_buffered = 1, redraw_on_alloc = 1, no_show_all = 0, child_visible = 1, multidevice = 0, has_shape_mask = 0, in_reparent = 0, resize_pending = 0, alloc_needed = 1, width_request_needed = 1, height_request_needed = 1, need_compute_expand = 0, computed_hexpand = 0, computed_vexpand = 0, hexpand = 0, vexpand = 0, hexpand_set = 0, vexpand_set = 0, sizegroup_visited = 0, sizegroup_bumping = 0, have_size_groups = 0, name = 0x0, style = 0x0, context = 0x9255660, allocation = {x = 6, y = 120, width = 1, height = 1}, requests = {widths = {{ for_size = -1, minimum_size = 0, natural_size = 0}, {for_size = 0, minimum_size = 0, natural_size = 0}, {for_size = 0, minimum_size = 0, natural_size = 0}}, heights = {{for_size = 0, minimum_size = 0, natural_size = 0}, {for_size = 1, minimum_size = 0, natural_size = 0}, {for_size = 1, minimum_size = 0, natural_size = 0}}, cached_widths = 1, cached_heights = 3, last_cached_width = 0, last_cached_height = 2}, window = 0x95d1ce8, parent = 0x806a188, path = 0x98d2b48} And the parent frame in html_engine_update_event: 4841 gtk_adjustment_set_value (vadjustment, e->y_offset); 4842 gtk_adjustment_set_value (hadjustment, e->x_offset); 4843 } 4844 html_image_factory_deactivate_animations (e->image_factory); 4845 gtk_container_forall (GTK_CONTAINER (e->widget), update_embedded, e->widget); 4846 html_engine_queue_redraw_all (e); 4847 4848 if (html_engine_get_editable (e)) 4849 html_engine_show_cursor (e);
*** Bug 647310 has been marked as a duplicate of this bug. ***
I was able to reproduce this with help of other people and the reason is that the gtk/evo is fighting whether to show the vertical scroll bar for the preview panel or not. When you have short-enough message then resize it that it will almost be completely visible in the preview panel and then see the scroll bar is shown, but the CPU is up as well. Changing preview's height a bit more (or less) stops this processing and everything is back in normal.
Hrm, I spent whole day on this, and I didn't find anything useful. I see that the GtkAdjustment within GtkHTML has set correct values for upper/lower limits, and has also correct page size (which indicates to show the scrollbar), but the scrollbar is hidden/shown periodically. I also noticed that this is behaving this strange only with iframes, thus a case where evolution shows an HTML email in the preview panel. It doesn't do this with plain text mails. I also know that I can avoid this recursion when I call parent's class calc_size at the end of html_iframe_real_calc_size, but it doesn't pain the iframe properly after wards, thus it's also not the right thing to do. After spending few hours staring into debug prints of something which is called really often I just say that I do not know how to fix this, I'm sorry.
*** Bug 659097 has been marked as a duplicate of this bug. ***
Created attachment 197023 [details] test message with instructions
*** Bug 660334 has been marked as a duplicate of this bug. ***
I noticed some behavior that I think is this bug. I am running the current 3.2.1-0ubuntu1 packages on 11.10 (unmodified source). Multiple times per day (pretty much whenever I send email) I have a condition where Evolution UI is stating "Saving user interface state" for extended periods of time. If I try to open my home directory in Nautilus at the same time, the window (nautilus) will only appear once the Evolution *spinning*/delay has come to an end. A common trick to trigger this 100% for me: 1) Send a message just subject "Test" to myself (which it sends, but then needs to copy into my IMAP+ Sent folder - I have multiple IMAP accounts, and this happens sending from any one to any other) 2) Click on Home Folder nautilus Icon just after sending (Send window is open stuck at "Sending 100%" 3) Move down my Inbox window list to try and update the preview pane, which is also stuck at "Retrieving message.." 4) Voila .. a big long pause on everything and the "Saving user interface state" Evolution status message (which may just be the last command / symptom of the big delay). 5) I go and do something else.. and when my Nautilus window pops up I know Evolution is finished holding things up. Considering my message has only the subject "Test" it seems like things are jammed up based on the loads shown below. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2608 imac 20 0 627m 108m 43m R 22 3.7 3:56.26 compiz 1599 root 20 0 388m 101m 78m R 17 3.5 5:11.02 Xorg 4563 imac 20 0 865m 106m 28m S 12 3.7 2:32.72 evolution
I think there is more to this, I have noticed what might be a related problem when vertical scroll exists in compiz with my Nautilus windows. I opened a separate downstream bug to try and separate this issue, if that is indeed the case. https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/889120
I think my case of preview pane issue was different than the original report. I resolved mine by stopping autofs which was somehow tying up certain apps like evolution and nautilus in a similar way.
*** Bug 661690 has been marked as a duplicate of this bug. ***
I discovered stopping autofs when not on my personal LAN resolved this issue. Seems my nfs auto mounts cause issues on external nets. In my case there appears to be no evo issue, as this same issue/symptoms were resolved in Nautilus and Shutter for myself.
*** Bug 673393 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > I was able to reproduce this with help of other people and the reason is that > the gtk/evo is fighting whether to show the vertical scroll bar for the preview > panel or not. When you have short-enough message then resize it that it will > almost be completely visible in the preview panel and then see the scroll bar > is shown, but the CPU is up as well. Changing preview's height a bit more (or > less) stops this processing and everything is back in normal. I confirm this.
*** Bug 678295 has been marked as a duplicate of this bug. ***
Since version 3.6, Evolution uses WebKit instead of GtkHtml for displaying messages. (And for completeness, Evolution 3.14 is planned to use WebKit also for composing and editing messages so GtkHtml will not receive any fixes anymore.) Hence I am closing this GtkHtml rendering bug report. We are sorry that your request was not handled in time when it was reported but unfortunately manpower is very limited (and does not allow testing every single reported issue separately again either). Please feel free to reopen this report (and move it to the "Evolution" product and the "Mail" component) if the problem described in this bug report still happens in a recent supported Evolution version which uses WebKit (the current stable Evolution version is 3.12).