After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 581150 - GtkIconView tries to paint items with invalid sizes
GtkIconView tries to paint items with invalid sizes
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkIconView
2.16.x
Other All
: Normal critical
: ---
Assigned To: gtk-bugs
gtk-bugs
evolution[attachments]
: 584868 588075 593292 597974 599320 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-05-03 02:38 UTC by David Ronis
Modified: 2009-10-28 21:00 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
Proposed patch (567 bytes, patch)
2009-10-22 20:42 UTC, Matthew Barnes
committed Details | Review

Description David Ronis 2009-05-03 02:38:35 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

Thread 1 (Thread 0xb6157700 (LWP 10011))

  • #0 *INT_cairo_line_to
    at cairo.c line 1433
  • #1 clearlooks_gummy_draw_progressbar_fill
    at ./src/clearlooks_draw_gummy.c line 420
  • #2 clearlooks_style_draw_box
    at ./src/clearlooks_style.c line 857
  • #3 IA__gtk_paint_box
  • #4 gtk_cell_renderer_progress_render
    at gtkcellrendererprogress.c line 600
  • #5 IA__gtk_cell_renderer_render
  • #6 gtk_icon_view_paint_item
    at gtkiconview.c line 3197
  • #7 gtk_icon_view_expose
    at gtkiconview.c line 1549
  • #8 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 84
  • #9 g_type_class_meta_marshal
    at gclosure.c line 878
  • #10 IA__g_closure_invoke
    at gclosure.c line 767
  • #11 signal_emit_unlocked_R
    at gsignal.c line 3285
  • #12 IA__g_signal_emit_valist
    at gsignal.c line 2990
  • #13 IA__g_signal_emit
    at gsignal.c line 3037
  • #14 gtk_widget_event_internal
    at gtkwidget.c line 4761
  • #15 IA__gtk_main_do_event
    at gtkmain.c line 1558
  • #16 gdk_window_process_updates_internal
    at gdkwindow.c line 2611
  • #17 IA__gdk_window_process_all_updates
    at gdkwindow.c line 2677
  • #18 gdk_window_update_idle
    at gdkwindow.c line 2521
  • #19 gdk_threads_dispatch
    at gdk.c line 498
  • #20 g_idle_dispatch
    at gmain.c line 3922
  • #21 IA__g_main_context_dispatch
    at gmain.c line 1814
  • #22 g_main_context_iterate
  • #23 IA__g_main_loop_run
    at gmain.c line 2656
  • #24 bonobo_main
    at bonobo-main.c line 311
  • #25 main
    at main.c line 704


Other information:
Comment 1 Matthew Barnes 2009-05-03 04:09:46 UTC
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.
Comment 2 Matthew Barnes 2009-05-03 04:11:11 UTC
Also, are you getting any WARNING or CRITICAL messages on the terminal?
Comment 3 David Ronis 2009-05-03 04:32:24 UTC
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.
Comment 4 Matthew Barnes 2009-05-03 11:24:40 UTC
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.

  • #0 IA__g_logv
  • #1 IA__g_log
    at gmessages.c line 526
  • #2 IA__g_return_if_fail_warning
    at gmessages.c line 541
  • #3 clearlooks_style_draw_box
    at ./src/clearlooks_style.c line 512
  • #4 IA__gtk_paint_box
    at gtkstyle.c line 6090
  • #5 gtk_cell_renderer_progress_render
    at gtkcellrendererprogress.c line 552
  • #6 IA__gtk_cell_renderer_render
    at gtkcellrenderer.c line 578
  • #7 gtk_icon_view_paint_item
    at gtkiconview.c line 3194
  • #8 gtk_icon_view_expose
    at gtkiconview.c line 1549
  • #9 _gtk_marshal_BOOLEAN__BOXED
    at gtkmarshalers.c line 84
  • #10 g_type_class_meta_marshal
    at gclosure.c line 878
  • #11 IA__g_closure_invoke
    at gclosure.c line 767
  • #12 signal_emit_unlocked_R
    at gsignal.c line 3285
  • #13 IA__g_signal_emit_valist
    at gsignal.c line 2990
  • #14 IA__g_signal_emit
    at gsignal.c line 3037
  • #15 gtk_widget_event_internal
    at gtkwidget.c line 4761
  • #16 IA__gtk_widget_send_expose
    at gtkwidget.c line 4590
  • #17 IA__gtk_main_do_event
    at gtkmain.c line 1558
  • #18 gdk_window_process_updates_internal
    at gdkwindow.c line 2611
  • #19 IA__gdk_window_process_all_updates
    at gdkwindow.c line 2677
  • #20 gtk_container_idle_sizer
    at gtkcontainer.c line 1353
  • #21 gdk_threads_dispatch
    at gdk.c line 498
  • #22 g_idle_dispatch
    at gmain.c line 3922
  • #23 g_main_dispatch
    at gmain.c line 1814
  • #24 IA__g_main_context_dispatch
    at gmain.c line 2367
  • #25 g_main_context_iterate
    at gmain.c line 2448
  • #26 IA__g_main_loop_run
    at gmain.c line 2656
  • #27 IA__gtk_main
    at gtkmain.c line 1205
  • #28 main
    at main.c line 769

Comment 5 Matthew Barnes 2009-05-03 11:42:31 UTC
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.
Comment 6 Matthew Barnes 2009-06-04 22:17:53 UTC
*** Bug 584868 has been marked as a duplicate of this bug. ***
Comment 7 Matthew Barnes 2009-07-08 15:15:45 UTC
*** Bug 588075 has been marked as a duplicate of this bug. ***
Comment 8 Matthew Barnes 2009-08-27 14:46:25 UTC
*** Bug 593292 has been marked as a duplicate of this bug. ***
Comment 9 Matthew Barnes 2009-10-10 21:43:03 UTC
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.
Comment 10 Matthew Barnes 2009-10-10 21:45:00 UTC
Apparently Bugzilla doesn't parse trace references, so here's the link:
https://bugzilla.gnome.org/page.cgi?id=trace.html&trace_id=218205
Comment 11 Matthew Barnes 2009-10-22 18:01:18 UTC
*** Bug 599320 has been marked as a duplicate of this bug. ***
Comment 12 Matthew Barnes 2009-10-22 20:42:10 UTC
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.
Comment 13 Matthias Clasen 2009-10-23 22:45:58 UTC
Since we're don't doing any of the incremental validation games that GtkTreeView does, this sounds like a reasonable approach.
Comment 15 Matthew Barnes 2009-10-28 21:00:57 UTC
*** Bug 597974 has been marked as a duplicate of this bug. ***