A patch has been proposed on the Ubuntu bug, and I will forward it as soon as it is verified to work.

Created attachment 146603 [details] [review]
add assertion for height and width

proposed patch. This, of course, does not solve the basic problem (width == 0, on the Ubuntu bug), but allows the system to survive.

Without this patch the system runs out of memory very fast.

Could you reproduce the bug with clearlooks?

I can reproduce this with clearlooks under Ubuntu 9.10 and Arch Linux.

No. I am actually unable to reproduce it with either Clearlooks, or Human, or
even Murrine. So... I still do not know what causes this.

stroke_width is height*2.0, so if height is = 0.0, then it enters the loop and doesn't exit.
Why on earth we are drawing a progressbar with height = 0?

(In reply to comment #6)
> stroke_width is height*2.0, so if height is = 0.0, then it enters the loop and
> doesn't exit.
> Why on earth we are drawing a progressbar with height = 0?

yes, that's a different bug somewhere in evolution (or gtk) ... but murrine definitely shouldn't go in infinite loop if that happen as height = 0 is strictly speaking a valid height. thanks for committing ;)

and yes, clearlooks suffers from the same problem:

from src/clearlooks_draw.c:922

       /* Draw the Strokes */
        while (tile_pos <= width+x_step)
        {
                cairo_move_to (cr, stroke_width/2-x_step, 0);
                cairo_line_to (cr, stroke_width-x_step,   0);
                cairo_line_to (cr, stroke_width/2-x_step, height);
                cairo_line_to (cr, -x_step, height);

                cairo_translate (cr, stroke_width, 0);
                tile_pos += stroke_width;
        }

Created attachment 146612 [details] [review]
same approach for clearlooks.

also checked the other engines in gtk-engines ... though seem to not do tiled progressbar drawing don't have code that would be affected.

if you can't review clearlooks patches, please CC someone who could drive that part so we do not have to open a new bug. Thanks!

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

Fixed also for clearlooks!

@Andrea -- I looked for the fix on GIT, but cannot find it...

(In reply to comment #13)
> @Andrea -- I looked for the fix on GIT, but cannot find it...

http://git.gnome.org/cgit/murrine/commit/?h=border-shade-and-expander&id=beaeda3e777f9e91a2f17d61584a38ee043b7866http://git.gnome.org/cgit/murrine/commit/?h=border-shade-and-expander&id=beaeda3e777f9e91a2f17d61584a38ee043b7866

(In reply to comment #14)
> (In reply to comment #13)
> > @Andrea -- I looked for the fix on GIT, but cannot find it...
> 
> http://git.gnome.org/cgit/murrine/commit/?h=border-shade-and-expander&id=beaeda3e777f9e91a2f17d61584a38ee043b7866http://git.gnome.org/cgit/murrine/commit/?h=border-shade-and-expander&id=beaeda3e777f9e91a2f17d61584a38ee043b7866

hmm ... so you think applications are not buggy if they pass-in height/width==0 ? otherwise, the assertions would have been the right approach to address this ...

I just made sure the engine won't loop in that while, I just don't care about the sizes, should not be engines's fault to monitor them.