GNOME Bugzilla – Bug 581150
GtkIconView tries to paint items with invalid sizes
Last modified: 2009-10-28 21:00:57 UTC
Steps to reproduce: 1. Select e-mail message 2. Press save and accept the suggested file name. 3. Stack trace: I've attached gdb to the hung process; here's what I get: 0xb677c34f in *INT_cairo_line_to (cr=0x8958900, x=0, y=0) at cairo.c:1433 1433 { (gdb) thread apply all bt full
+ Trace 215045
Thread 1 (Thread 0xb6157700 (LWP 10011))
Other information:
You're running the master branch, soon to be 2.27.1, correct? I think this is a ClearLooks (and/or GTK+) bug. To verify, try switching themes and checking whether the problem still occurs.
Also, are you getting any WARNING or CRITICAL messages on the terminal?
1. I am indeed running the master branch 2. Your guess is probably correct. Rerunning from the console shows: ** (evolution:13058): CRITICAL **: clearlooks_style_draw_box: assertion `width >= -1' failed just after I pressed save and evo hung. 3. I changed the them (to Crux) and the probem didn't occur.
Here's a stacktrace at the point where the CRITICAL warning occurs. You can see in frame #3 gtk_paint_box() is passing ClearLooks a width of -13.
+ Trace 215053
This may be a ClearLooks bug, but reassigning to GTK+ first. Problem summary: In my attachment UI rewrite for Evolution (version 2.27.1), I'm using a GtkIconView with custom cell renderers. They are (in order): - GtkCellRendererPixbuf for the attachment icon - GtkCellRendererText for the attachment filename - GtkCellRendererProgress for file loading progress - GtkCellRendererProgress for file saving progress The two progress renderers are never both visible at once, and both are invisible when no file operation is in progress. The problem is triggered by loading or saving an attachment -- which causes one of the progress renderers to become visible -- but isn't 100% repeatable. gtk_cell_renderer_progress_render() seems to be miscalculating the width during an "expose" event, coming up with a negative value that ClearLooks doesn't like. Somehow this causes GTK+ to get into an endless loop, which hangs the application. Other theme engines seem to handle or ignore the negative width. I'm working on a reproducer program to help isolate the cause.
*** Bug 584868 has been marked as a duplicate of this bug. ***
*** Bug 588075 has been marked as a duplicate of this bug. ***
*** Bug 593292 has been marked as a duplicate of this bug. ***
Had a similar bug reported by someone using the Murrine theme engine (bug #597974), which makes me believe this is a GtkIconView issue. Trace #218205 in that bug also shows gtk_cell_renderer_progress_render() passing a negative width value to gtk_paint_box(), which theme engines seem to not take kindly to.
Apparently Bugzilla doesn't parse trace references, so here's the link: https://bugzilla.gnome.org/page.cgi?id=trace.html&trace_id=218205
*** Bug 599320 has been marked as a duplicate of this bug. ***
Created attachment 146064 [details] [review] Proposed patch Think I figured out what's causing the hangs. As GtkIconView rows are inserted or changed, GtkIconViewItems get created or their sizes are invalidated. Either way, their dimensions are set to -1. We then call gtk_icon_view_queue_layout(), which schedules gtk_icon_view_layout() to be run in an idle callback. This calculates new sizes for the items. What's happening is we're getting expose events before the idle callback gets a chance to run, and the expose handler does not check for invalid item sizes before attempting to paint the items. My solution is to simply check for a scheduled idle callback at the beginning of the expose handler and call gtk_icon_view_layout() immediately if it's already scheduled (it's smart enough to unschedule itself). I haven't been able to reproduce the hang with this patch, but I'm not sure if there's any hidden side-effects to running the layout logic during an expose.
Since we're don't doing any of the incremental validation games that GtkTreeView does, this sounds like a reasonable approach.
Committed the patch to master and gtk-2-18: http://git.gnome.org/cgit/gtk+/commit/?id=13d968adbed19502cce23c92582f0dc3366a9614 http://git.gnome.org/cgit/gtk+/commit/?h=gtk-2-18&id=e3b14b6652069621236c13b75846620f2372a387
*** Bug 597974 has been marked as a duplicate of this bug. ***