Evolution hangs when double-clicking on attachment

Workaround: right-click on the attachment and choose "Open with ..."

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Please try to obtain a backtrace manually of the hang following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

I confirm, it happens for me too, latest from Karmic, both 32bit and 64bit.
It doesn't crash, it just freezes, suck 100% instantaneously and 100% memory in a few seconds (huge leak).

here is a 'ps' every 2 sec:

fta 6308 4.9 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.9 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.9 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.8 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.8 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.8 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.8 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.8 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.8 4.1 221632 86472 ? Sl 22:33 0:25 evolution --component=mail
fta 6308 4.8 4.1 221632 86472 ? Rl 22:33 0:25 evolution --component=mail
fta 6308 4.9 4.2 222172 86648 ? Sl 22:33 0:26 evolution --component=mail
fta 6308 4.9 4.2 222172 86648 ? Sl 22:33 0:26 evolution --component=mail
fta 6308 4.9 4.2 222172 86648 ? Sl 22:33 0:26 evolution --component=mail
fta 6308 5.0 6.1 361176 127772 ? Rl 22:33 0:27 evolution --component=mail <= here I double-click an attachment (a .doc)
fta 6308 5.4 11.5 778968 238360 ? Rl 22:33 0:29 evolution --component=mail
fta 6308 5.7 16.8 778968 346664 ? Rl 22:33 0:31 evolution --component=mail
fta 6308 6.1 22.0 1336024 455536 ? Rl 22:33 0:33 evolution --component=mail
fta 6308 6.4 27.5 1336024 567204 ? Rl 22:33 0:35 evolution --component=mail
fta 6308 6.8 32.8 2450136 677464 ? Rl 22:33 0:37 evolution --component=mail
fta 6308 7.1 38.1 2450136 787260 ? Rl 22:33 0:39 evolution --component=mail
fta 6308 7.5 43.4 2450136 895872 ? Rl 22:33 0:41 evolution --component=mail
fta 6308 7.8 48.8 2450136 1006372 ? Rl 22:33 0:43 evolution --component=mail
fta 6308 8.2 53.3 2450136 1100348 ? Rl 22:33 0:45 evolution --component=mail
fta 6308 8.5 58.4 2450136 1205988 ? Rl 22:33 0:47 evolution --component=mail
fta 6308 8.8 61.3 2450136 1265496 ? Rl 22:33 0:49 evolution --component=mail
fta 6308 9.2 61.3 2450136 1265496 ? Rl 22:33 0:51 evolution --component=mail
fta 6308 9.5 61.3 2450136 1265496 ? Rl 22:33 0:53 evolution --component=mail
fta 6308 9.8 61.3 2450136 1265496 ? Rl 22:33 0:55 evolution --component=mail
fta 6308 10.1 61.3 2450136 1265496 ? Rl 22:33 0:57 evolution --component=mail
fta 6308 10.5 61.3 2450136 1265496 ? Rl 22:33 0:59 evolution --component=mail
fta 6308 10.8 61.3 2450136 1265496 ? Rl 22:33 1:01 evolution --component=mail
fta 6308 11.1 61.3 2450136 1265496 ? Rl ...

hmm.. in gdb, if i break it, it's always in cairo called from murrine_draw_progressbar_fill() in libmurrine: http://paste.ubuntu.com/304600/

@Fabian: would you mind getting a backtrace? I cannot reproduce...

==8957== 142,603,520 bytes in 16 blocks are possibly lost in loss record 26,949 of 26,950
==8957== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==8957== by 0x53FD4CD: _cairo_path_buf_create (cairo-path-fixed.c:427)
==8957== by 0x53FD5C8: _cairo_path_fixed_add (cairo-path-fixed.c:395)
==8957== by 0x53FD941: _cairo_path_fixed_line_to (cairo-path-fixed.c:263)
==8957== by 0x53EC6D0: cairo_line_to (cairo.c:1447)
==8957== by 0x650A693: murrine_draw_progressbar_fill (murrine_draw.c:645)
==8957== by 0x6504A38: murrine_style_draw_box (murrine_style.c:1025)
==8957== by 0x4FDA44D: gtk_paint_box (gtkstyle.c:6090)
==8957== by 0x4EABF81: gtk_cell_renderer_progress_render (gtkcellrendererprogress.c:600)
==8957== by 0x4EA7675: gtk_cell_renderer_render (gtkcellrenderer.c:578)
==8957== by 0x4F27861: gtk_icon_view_paint_item (gtkiconview.c:3222)
==8957== by 0x4F31FE6: gtk_icon_view_expose (gtkiconview.c:1574)
==8957== by 0x4F5C473: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
==8957== by 0x55786F8: g_type_class_meta_marshal (gclosure.c:878)
==8957== by 0x557A071: g_closure_invoke (gclosure.c:767)
==8957== by 0x558F49D: signal_emit_unlocked_R (gsignal.c:3285)
==8957== by 0x55909B7: g_signal_emit_valist (gsignal.c:2990)
==8957== by 0x5590FB5: g_signal_emit (gsignal.c:3037)
==8957== by 0x507896D: gtk_widget_event_internal (gtkwidget.c:4767)
==8957== by 0x4F5618F: gtk_main_do_event (gtkmain.c:1571)
==8957== by 0x525E1D3: _gdk_window_process_updates_recurse (gdkwindow.c:5061)
==8957== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==8957== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==8957== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==8957== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==8957== by 0x5281733: _gdk_windowing_window_process_updates_recurse (gdkwindow-x11.c:5566)
==8957== by 0x525587E: gdk_window_process_updates_internal (gdkwindow.c:5220)
==8957== by 0x525783E: gdk_window_process_all_updates (gdkwindow.c:5328)
==8957== by 0x52578BA: gdk_window_update_idle (gdkwindow.c:4954)
==8957== by 0x5233F77: gdk_threads_dispatch (gdk.c:506)
==8957== by 0x55E90F0: g_idle_dispatch (gmain.c:4065)
==8957== by 0x55EAE77: g_main_context_dispatch (gmain.c:1960)
==8957== by 0x55EE71F: g_main_context_iterate (gmain.c:2591)
==8957== by 0x55EEB8E: g_main_loop_run (gmain.c:2799)
==8957== by 0x4B72C22: bonobo_main (in /usr/lib/libbonobo-2.so.0.0.0)
==8957== by 0x805E13E: main (main.c:732)
==8957==
==8957== LEAK SUMMARY:
==8957== definitely lost: 57,484 bytes in 474 blocks
==8957== indirectly lost: 38,184 bytes in 1,820 blocks
==8957== possibly lost: 174,848,047 bytes in 936,041 blocks
==8957== still reachable: 1,003,217,423 bytes in 35,401 blocks
==8957== suppressed: 30,076 bytes in 649 blocks

so we seem to be lost in Cairo... I wonder...

Fabian, does it happen on *any* attachments? Are you running Karmic? Could I have this attachment?

here it is:

==9730== 998,245,280 bytes in 4 blocks are still reachable in loss record 27,109 of 27,109
==9730== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==9730== by 0x53FD4CD: _cairo_path_buf_create (cairo-path-fixed.c:427)
==9730== by 0x53FD5C8: _cairo_path_fixed_add (cairo-path-fixed.c:395)
==9730== by 0x53FD941: _cairo_path_fixed_line_to (cairo-path-fixed.c:263)
==9730== by 0x53EC6D0: cairo_line_to (cairo.c:1447)
==9730== by 0x650A693: murrine_draw_progressbar_fill (murrine_draw.c:645)
==9730== by 0x6504A38: murrine_style_draw_box (murrine_style.c:1025)
==9730== by 0x4FDA44D: gtk_paint_box (gtkstyle.c:6090)
==9730== by 0x4EABF81: gtk_cell_renderer_progress_render (gtkcellrendererprogress.c:600)
==9730== by 0x4EA7675: gtk_cell_renderer_render (gtkcellrenderer.c:578)
==9730== by 0x4F27861: gtk_icon_view_paint_item (gtkiconview.c:3222)
==9730== by 0x4F31FE6: gtk_icon_view_expose (gtkiconview.c:1574)
==9730== by 0x4F5C473: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
==9730== by 0x55786F8: g_type_class_meta_marshal (gclosure.c:878)
==9730== by 0x557A071: g_closure_invoke (gclosure.c:767)
==9730== by 0x558F49D: signal_emit_unlocked_R (gsignal.c:3285)
==9730== by 0x55909B7: g_signal_emit_valist (gsignal.c:2990)
==9730== by 0x5590FB5: g_signal_emit (gsignal.c:3037)
==9730== by 0x507896D: gtk_widget_event_internal (gtkwidget.c:4767)
==9730== by 0x4F5618F: gtk_main_do_event (gtkmain.c:1571)
==9730== by 0x525E1D3: _gdk_window_process_updates_recurse (gdkwindow.c:5061)
==9730== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==9730== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==9730== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==9730== by 0x525E182: _gdk_window_process_updates_recurse (gdkwindow.c:5034)
==9730== by 0x5281733: _gdk_windowing_window_process_updates_recurse (gdkwindow-x11.c:5566)
==9730== by 0x525587E: gdk_window_process_updates_internal (gdkwindow.c:5220)
==9730== by 0x525783E: gdk_window_process_all_updates (gdkwindow.c:5328)
==9730== by 0x52578BA: gdk_window_update_idle (gdkwindow.c:4954)
==9730== by 0x5233F77: gdk_threads_dispatch (gdk.c:506)
==9730== by 0x55E90F0: g_idle_dispatch (gmain.c:4065)
==9730== by 0x55EAE77: g_main_context_dispatch (gmain.c:1960)
==9730== by 0x55EE71F: g_main_context_iterate (gmain.c:2591)
==9730== by 0x55EEB8E: g_main_loop_run (gmain.c:2799)
==9730== by 0x4B72C22: bonobo_main (in /usr/lib/libbonobo-2.so.0.0.0)
==9730== by 0x805E13E: main (main.c:732)
==9730==
==9730== LEAK SUMMARY:
==9730== definitely lost: 27,702 bytes in 256 blocks
==9730== indirectly lost: 38,084 bytes in 1,863 blocks
==9730== possibly lost: 160,308,264 bytes in 499,885 blocks
==9730== still reachable: 1,002,888,666 bytes in 50,316 blocks
==9730== suppressed: 30,744 bytes in 665 blocks

This is with:
evolution 2.28.1-0ubuntu1
gtk2-engines-murrine 0.90.3-1ubuntu1
libcairo2 1.8.8-2ubuntu1

==9730== by 0x650A693: murrine_draw_progressbar_fill (murrine_draw.c:645)

static void
murrine_draw_progressbar_fill (cairo_t *cr,
                               const MurrineColors *colors,
                               const WidgetParameters *widget,
                               const ProgressBarParameters *progressbar,
                               int x, int y, int width, int height,
                               gint offset)
{

...
                        /* Draw strokes */
                        while (tile_pos <= width+x_step-2)
                        {
                                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); <=========== line 645

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

...
}

oh, and one last thing, i'm using Darkroom + Human.
And it happens almost 100% of the time with *.doc and *.ppt attachments (doesn't matter how many), not with *.txt (probably because they are smaller and the att progress bar is not visible)

so from what i see the drawing loop you pasted in comment #11 is an infinite loop because as the backtrace in comment #6 shows, height = 0 ... which causes stroke_width = 0 ... which means that tile_pos + = stroke_width in the loop never increases and the loop ends up looping forever.

so first i think that murrine engine should not allow height= 0 to end up in such a situation ... and rather add a g_return_if_fail (height) or something to the top of that _fill function.

secondly i wonder if its a valid condition gtk+ wise to have that call with height = 0 ... if not, we should check why that happens and maybe fix that in gtk+ or evolution.

if height=0 is a valid condition, the loop could also just do a "while (height && tile_pos <= width+x_step-2)" ...

at least the other style type (->style = 2) seems to not end in such a loop if height = 0.

For the record (and since I do not know how long a pastebin survives), here's Fabien's BT:

^C
Program received signal SIGINT, Interrupt.
0x02a9b1a7 in *INT_cairo_matrix_transform_point (matrix=0x898d554, x=0xbfffe7e8, y=0xbfffe7e0) at /build/buildd/cairo-1.8.8/src/cairo-matrix.c:359
359 /build/buildd/cairo-1.8.8/src/cairo-matrix.c: No such file or directory.
        in /build/buildd/cairo-1.8.8/src/cairo-matrix.c
(gdb) bt
#0 0x02a9b1a7 in *INT_cairo_matrix_transform_point (matrix=0x898d554, x=0xbfffe7e8, y=0xbfffe7e0) at /build/buildd/cairo-1.8.8/src/cairo-matrix.c:359
#1 0x02a906a1 in *INT_cairo_line_to (cr=0x894c1f8, x=12, y=0) at /build/buildd/cairo-1.8.8/src/cairo.c:1443
#2 0x013b067b in murrine_draw_progressbar_fill (cr=0x894c1f8, colors=0x8765c88, widget=0xbfffe9f8, progressbar=0xbfffeb0c, x=12, y=0, width=2, height=0, offset=10) at ./src/murrine_draw.c:644
#3 0x013aaa39 in murrine_style_draw_box (style=0x8765998, window=0x8692800, state_type=GTK_STATE_SELECTED, shadow_type=GTK_SHADOW_OUT, area=0xbfffec10, widget=0x87f82f8,
    detail=0x6883162 "bar", x=13, y=0, width=0, height=0) at ./src/murrine_style.c:1025
#4 0x0675544e in IA__gtk_paint_box (style=0x8765998, window=0x8692800, state_type=GTK_STATE_SELECTED, shadow_type=GTK_SHADOW_OUT, area=0xbfffec10, widget=0x87f82f8, detail=0x6883162 "bar",
    x=13, y=0, width=0, height=0) at /build/buildd/gtk+2.0-2.18.3/gtk/gtkstyle.c:6090
#5 0x06626f82 in gtk_cell_renderer_progress_render (cell=0x86ff438, window=0x8692800, widget=0x87f82f8, background_area=0xbfffed0c, cell_area=0xbfffed0c, expose_area=0xbffff254, flags=1)
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkcellrendererprogress.c:600
#6 0x06622676 in IA__gtk_cell_renderer_render (cell=0x86ff438, window=0x8692800, widget=0x87f82f8, background_area=0xbfffed0c, cell_area=0xbfffed0c, expose_area=0xbffff254,
    flags=<value optimized out>) at /build/buildd/gtk+2.0-2.18.3/gtk/gtkcellrenderer.c:578
#7 0x066a2862 in gtk_icon_view_paint_item (icon_view=<value optimized out>, cr=<value optimized out>, item=0x895a770, area=0xbffff254, drawable=0x8692800, x=7, y=7, draw_focus=0)
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkiconview.c:3222
#8 0x066acfe7 in gtk_icon_view_expose (widget=0x87f82f8, expose=0xbffff248) at /build/buildd/gtk+2.0-2.18.3/gtk/gtkiconview.c:1574
#9 0x066d7474 in _gtk_marshal_BOOLEAN__BOXED (closure=0x80b26c0, return_value=0xbfffef94, n_param_values=2, param_values=0xb1f09278, invocation_hint=0xbfffef80, marshal_data=0x66aceb0)
    at /build/buildd/gtk+2.0-2.18.3/gtk/gtkmarshalers.c:84
#10 0x00ed46f9 in g_type_class_meta_marshal (closure=0x80b26c0, return_value=0xbfffef94, n_param_values=2, param_values=0xb1f09278, invocation_hint=0xbfffef80, marshal_data=0xc8)
    at /build/buildd/glib2.0-2.22.2/gobject/gclosure.c:878
#11 0x00ed6072 in IA__g_closure_invoke (closure=0x80b26c0, return_value=0xbfffef94, n_param_values=2, param_values=0xb1f09278, invocation_hint=0xbfffef80)
    at /build/buildd/glib2.0-2.22.2/gobject/gclosure.c:767
#12 0x00eeb49e in signal_emit_unlocked_R (node=<value optimized out>, detail=<value optimized out>, instance=0x87f82f8, emission_return=0xbffff0dc, instance_and_params=0xb1f09278)
    at ...

infinite loops in drawing is kind of devastating and murrine should do proper assertions (like in the patch in last comment) ...

please forward this patch upstream if it works ...

... and thanks "C de-Avillez" for making fta's backtrace persistent ...

Hey, I'm the maintainer of murrine, thanks for pointing this out...

Patch submitted upstream. Per IRC exchange with fta, now he can open the attachments, and keep on working. He only does not get to see the progress bar on Evo.

Could you reproduce with clearlooks or it is just Human/murrine?

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

yes, clearlooks suffers the same infinite loop condition afaik

added gtk2-engines package for clearlooks part ...

Fabien or someone willing to guide this in as a SRU while I am on vacation next week?

I will get it done, for murrine and clearlooks, on Monday.

There is bug 393534 that deals with a (somewhat) similar issue, and GTK+ itself has been fixed, and is getting into karmic-proposed now. It would be nice to see if this fixes this bug also. I would like to have a feedback on that.

Of course, the assertion is still a sane option to have in murrine or clearlooks.

Sigh. Forgot it should be built against karmic-proposed. Redoing the diff.

This debdiff is for karmic-proposed.

I've sponsored the gtk2-engines-murrine, did a second upload to include the bug number in a format lp understand too there

gtk2-engines uploaded too

I rejected the gtk2-engines-murrine upload. The diff adds a patch 01-I-don-t-know-why-I-had-x_step-2-here-maybe-to-avoid-.patch to series, but doesn't actually contain that patch. Please fix and reupload (same version number).

Accepted gtk2-engines into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted gtk2-engines-murrine into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Per the easily repeatable scenario documented in https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/445435 (duplicate) using http://launchpadlibrarian.net/33234697/test.tif, evolution is still hanging when previewing the inline attachment.

ii gtk2-engines 1:2.18.4-1ubuntu2
ii gtk2-engines-murrine 0.90.3-1ubuntu2
ii gtk2-engines-pixbuf 2.18.3-1ubuntu1
ii libgtk2.0-0 2.18.3-1ubuntu1
ii libgtk2.0-bin 2.18.3-1ubuntu1
ii libgtk2.0-cil 2.12.9-1
ii libgtk2.0-common 2.18.3-1ubuntu1
ii libgtk2.0-dev 2.18.3-1ubuntu1

Sticking to Crux for now

Brilliant - had the bug again this morning (had to force-quit evolution), enabled karmic proposed, installed all proposed, tried sending exact same email, same attachment, worked fine this time: great work, fix works as promised.

This bug was fixed in the package gtk2-engines-murrine - 0.90.3-1ubuntu2

---------------
gtk2-engines-murrine (0.90.3-1ubuntu2) karmic-proposed; urgency=low

  * murrine fix for bug LP: #460710
    - add ./debian/patches
    - cherry-pick GIT commits:
    - debian/patches/01-I-don-t-know-why-I-had-x_step-2-here-maybe-to-avoid-.patch
       GIT commit 1c36c51a94716a34567d21390908616cdf89f832
    - debian/patches/02-Fix-a-potential-endless-loop-in-draw_progressbar_fil.patch
       GIT commint beaeda3e777f9e91a2f17d61584a38ee043b7866
    - debian/patches/series: added.
    - debian/rules: augmented to deal with quilt patches.
      I could have consolidated them, but this makes it easier to cross-check.
    - debian/control: added quilt as a build-depends.

 -- C de-Avillez <email address hidden> Mon, 02 Nov 2009 13:27:35 -0600

gtk2-engines (1:2.18.4-1ubuntu2) karmic-proposed; urgency=low

  * /debian/patches/50-fix-potential-endless-loop.patch:
    fix a potential endless loop on drawing (LP: 460710)

 -- C de-Avillez <email address hidden> Mon, 02 Nov 2009 16:38:57 -0600

Copied to lucid, too

is there still an evolution bug there or should it be closed?

Has been resolved.
It can be closed.

----- Original Message -----
From: "Sebastien Bacher" <email address hidden>
To: <email address hidden>
Sent: Thursday, December 17, 2009 11:56 AM
Subject: [Bug 460710] Re: Evolution hangs when double-clicking on attachment

is there still an evolution bug there or should it be closed?

--
Evolution hangs when double-clicking on attachment
https://bugs.launchpad.net/bugs/460710
You received this bug notification because you are a direct subscriber
of the bug.

Status in The Evolution Mail & Calendaring Tool: Unknown
Status in “evolution” package in Ubuntu: Confirmed
Status in “gtk2-engines” package in Ubuntu: Fix Released
Status in “gtk2-engines-murrine” package in Ubuntu: Fix Released
Status in “evolution” source package in Lucid: Confirmed
Status in “gtk2-engines” source package in Lucid: Fix Released
Status in “gtk2-engines-murrine” source package in Lucid: Fix Released
Status in “evolution” source package in Karmic: New
Status in “gtk2-engines” source package in Karmic: Fix Released
Status in “gtk2-engines-murrine” source package in Karmic: Fix Released
Status in “evolution” package in Arch Linux: New

Bug description:
Binary package hint: evolution

[9.10 RC + some updates] Evolution hangs when I:
1) select an email with an attachment from an IMAPS account (don't know if
its related to IMAP)
2) open the bar that contains the attachments by clicking on the arrow
3) double-click on the attachment

100% reproducible

ProblemType: Bug
Architecture: amd64
Date: Sun Oct 25 23:29:49 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/evolution
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release Candidate amd64
(20091020.3)
NonfreeKernelModules: nvidia
Package: evolution 2.28.1-0ubuntu1
ProcEnviron:
LANG=de_AT.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: evolution
Uname: Linux 2.6.31-14-generic x86_64

WORKAROUND:

asac's patch bypasses the consequence (infinite loop, with high CPU usage
and eating up all memory). Of course, *why* height == 0 is another issue.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/evolution/+bug/460710/+subscribe

Have never seen a more devastating memory leak.