Bug 187565

This is happening frequently.

This is increasingly frequent now -- it's happened five times in the last ten
minutes. Probably because mailboxes are growing in size over time -- it
definitely seems to happen more when I'm looking at larger mailboxes.

This is continuing to get worse over time, as mailboxes grow. It's crashing
10-20 times daily at the moment. One of its crashes yesterday lost a mail I was
composing -- and it didn't get recovered either.

I have about 1000 mails in evolution and no crashes at all. How many mails do
you have? Im' running an up to date FC5.

The linux-kernel folder has 15554 of which 13971 are unread. I've also started
to see it on the fedora-devel-list, which has only 2363 mails (1550 unread).

My linux-kernel folder has 243445 messages. I marked all of them unread, browsed
around a bit (marking messages read at random), and experienced no errors. So,
it doesn't look like this is related to folder size or unread message count.

This is with almost-stock FC5 Evolution.

David,

are you running on ppc ?

yes

I've attached a patch to the GNOME bug which 'fixes' the problem for me, by
disabling the broken code which highlights the thread 'expander' when you're
viewing a folder in threaded mode.

It only actually manages that in the first 1024 or so rows of the folder. It
then draws it in the wrong place for the next few rows, and further down the
folder it seems to miscalculate things so badly that it causes the crash I've
been seeing.

As noted in the GNOME bug, that patch fixes only the mouse-over crash. If you
actually click on one of the expanders after row 2048, there's an animation
which suffers the same problems, and causes a similar crash.

managed to get a backtrace on this finally. needed cairo, gtk2, and libX11 
debuginfo packages. used set args to add --sync to the evolution commandline 
for the debugger.

(gdb) break exit
Breakpoint 2 at 0x12b8ae
(gdb) run
Starting program: /usr/bin/evolution --sync
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x472000
[Thread debugging using libthread_db enabled]
[New Thread -1208248640 (LWP 5703)]
Detaching after fork from child process 5730.
[New Thread -1231336544 (LWP 5731)]

(evolution-2.6:5703): camel-WARNING **: camel_exception_get_id called with NULL 
parameter.
[New Thread -1252316256 (LWP 5733)]
[New Thread -1241826400 (LWP 5732)]
Detaching after fork from child process 5734.
[New Thread -1252975712 (LWP 5735)]
[New Thread -1263465568 (LWP 5736)]
libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name 
org.freedesktop.NetworkManager was not provided by any .service files
Detaching after fork from child process 5737.
[New Thread -1273955424 (LWP 5742)]
Detaching after fork from child process 5743.
[Thread -1252975712 (LWP 5735) exited]
Detaching after fork from child process 5745.
The program 'evolution-2.6' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 2130 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[Switching to Thread -1208248640 (LWP 5703)]

Breakpoint 2, 0x0012b8ae in exit () from /lib/libc.so.6
(gdb) bt
#0  0x0012b8ae in exit () from /lib/libc.so.6
#1  0x02d6d227 in gdk_error_trap_push () from /usr/lib/libgdk-x11-2.0.so.0
#2  0x00b25955 in bonobo_ui_gtk_module_info_get () from /usr/lib/libbonoboui-
2.so.0
#3  0x002749ea in _XError (dpy=0x808cc40, rep=0xbffe7cb0) at XlibInt.c:2886
#4  0x00276654 in _XReply (dpy=0x808cc40, rep=0xbffe7cb0, extra=0, discard=1) 
at XlibInt.c:1815
#5  0x0026d40a in XSync (dpy=0x808cc40, discard=0) at Sync.c:48
#6  0x0026d585 in _XSyncFunction (dpy=0x808cc40) at Synchro.c:37
#7  0x0024fc5d in XCreatePixmap (dpy=0x808cc40, d=31457533, width=Variable 
"width" is not available.
) at CrPixmap.c:58
#8  0x02d6e46d in gdk_pixmap_new () from /usr/lib/libgdk-x11-2.0.so.0
#9  0x02d4f083 in gdk_window_begin_paint_region () from /usr/lib/libgdk-x11-
2.0.so.0
#10 0x04b4b3c5 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x02d4f48f in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0
#12 0x02d4f58b in gdk_window_process_updates () from /usr/lib/libgdk-x11-
2.0.so.0
#13 0x04b3eae0 in gtk_layout_get_hadjustment () from /usr/lib/libgtk-x11-
2.0.so.0
#14 0x0050c1d9 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-
2.0.so.0
#15 0x004fef8b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#16 0x0050fe3d in g_signal_override_class_closure () from /usr/lib/libgobject-
2.0.so.0
#17 0x00511347 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#18 0x00511509 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#19 0x04a7ad03 in gtk_adjustment_value_changed () from /usr/lib/libgtk-x11-
2.0.so.0
#20 0x0751919f in gtk_html_get_selection_html () from /usr/lib/libgtkhtml-
3.8.so.15
#21 0x0050b849 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-
2.0.so.0
#22 0x004fd7a9 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#23 0x004ff06d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#24 0x005102ca in g_signal_override_class_closure () from /usr/lib/libgobject-
2.0.so.0
#25 0x00511347 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#26 0x00511509 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#27 0x04c4076a in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0
#28 0x04b8e9d3 in gtk_scrolled_window_new () from /usr/lib/libgtk-x11-2.0.so.0
#29 0x0050b849 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-
2.0.so.0
#30 0x004fd7a9 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#31 0x004ff06d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#32 0x005102ca in g_signal_override_class_closure () from /usr/lib/libgobject-
2.0.so.0
#33 0x00511347 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#34 0x00511509 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#35 0x04c4076a in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0
#36 0x04c39731 in gtk_vpaned_new () from /usr/lib/libgtk-x11-2.0.so.0
#37 0x0050b849 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-
2.0.so.0
#38 0x004fd7a9 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#39 0x004ff06d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#40 0x005102ca in g_signal_override_class_closure () from /usr/lib/libgobject-
2.0.so.0
#41 0x00511347 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#42 0x00511509 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#43 0x04c4076a in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0
#44 0x04c377e2 in gtk_vbox_new () from /usr/lib/libgtk-x11-2.0.so.0
#45 0x0050b849 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-
2.0.so.0
#46 0x004fd7a9 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#47 0x004ff06d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#48 0x005102ca in g_signal_override_class_closure () from /usr/lib/libgobject-
2.0.so.0
#49 0x00511347 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#50 0x00511509 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#51 0x04c4076a in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0
#52 0x04b7607b in gtk_plug_get_id () from /usr/lib/libgtk-x11-2.0.so.0
#53 0x00b2f4d6 in bonobo_plug_new () from /usr/lib/libbonoboui-2.so.0
#54 0x0050b849 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-
2.0.so.0
#55 0x004fd7a9 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#56 0x004fef8b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#57 0x005102ca in g_signal_override_class_closure () from /usr/lib/libgobject-
2.0.so.0
#58 0x00511347 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#59 0x00511509 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#60 0x04c4076a in gtk_widget_size_allocate () from /usr/lib/libgtk-x11-2.0.so.0
#61 0x04abd22c in gtk_container_resize_children () from /usr/lib/libgtk-x11-
2.0.so.0
#62 0x04abf4a8 in gtk_container_child_type () from /usr/lib/libgtk-x11-2.0.so.0
#63 0x04b7520f in gtk_pixmap_new () from /usr/lib/libgtk-x11-2.0.so.0
#64 0x0050c1d9 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-
2.0.so.0
#65 0x004fd7a9 in g_value_set_static_boxed () from /usr/lib/libgobject-2.0.so.0
#66 0x004fef8b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#67 0x00510483 in g_signal_override_class_closure () from /usr/lib/libgobject-
2.0.so.0
#68 0x00511347 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#69 0x00511509 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#70 0x04abd2c3 in gtk_container_check_resize () from /usr/lib/libgtk-x11-
2.0.so.0
#71 0x04abd343 in gtk_container_check_resize () from /usr/lib/libgtk-x11-
2.0.so.0
#72 0x007397a1 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#73 0x0073b15d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#74 0x0073e3ef in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#75 0x0073e799 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#76 0x00894b83 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#77 0x0805e0f0 in main (argc=2, argv=0xbffea754) at main.c:611
#78 0x00116724 in __libc_start_main () from /lib/libc.so.6
#79 0x0804fc91 in _start ()
(gdb) 

This may help

I cannot currently get into my evo mail AT ALL, and I rely on this on a daily 
basis for my job. What can I do to retrieve read and respond to my existing 
mail?

That looks like a different crash to the one I saw.

I'd suggest opening a separate bug for it.

No, it's the same bug, just with far more detailed crash information.

packages evolution-debuginfo, gtk2-debuginfo, cairo-debuginfo, and libX11-
debuginfo were additionally installed to provide backtrace information from gdb.

then I ran 
gdb evolution
and entered
set args --sync
break exit
run

the result is what you see above. Originally all I saw was the exact same thing 
you pasted in your original bug report. 

This is a serious showstopping bug; I can't get into my email at all. 

It looks like a different backtrace to the one I filed. Read the GNOME bug.

Also, the crash I see is only when I move the mouse over, or click on, a 'thread
expander'. It's different.

maybe so, but it's still an "Evolution aborts with BadAlloc error". If the 
Gnome folks think I should file a separate bug, I will do so, however I believe 
they may be related.

For anyone else experiencing this, I've discovered that I can get in to the 
program by using the commandline option 

  evolution -c calendar

to open it with the calendar module up front. After which, I experience no 
further crashing once switched to the Mail component. (which I find somewhat 
mysterious.) However I still continue to experience the crash if I launch 
evolution with no other args. This is a temporary workaround, but seems to work 
for me. time will tell.

(In reply to comment #15)
> maybe so, but it's still an "Evolution aborts with BadAlloc error". 

I've made the summary more specific, now that we have more information about the
crash I was seeing. I'd done that in GNOME bugzilla, but not here. Thanks for
the reminder.

> If the Gnome folks think I should file a separate bug, I will do so, however
> I believe they may be related.

I don't see why the GNOME folks would comment on your misuse of this bug in Red
Hat bugzilla. Feel free to file your entirely different backtrace against GNOME
bug #336803 and see what they say though :)

This is still happening in FC6. I'm using my own builds of Evolution with the
patch to work around it, for now.

On x86/AMD64, the expander arrows towards the end of a large mailbox aren't
colored on mouse over, but Evo doesn't crash.

I can reproduce the misdrawn expander arrows on Evolution 2.8.1.  I'm seeing
behavior similar to what you observed in [1], but no crash (yet).

In a folder of 3261 messages grouped by threads, the arrows start misbehaving
for me around message 830.  This continues for maybe 5 to 10 more arrows, and
subsequent expander arrows appear to do nothing when the mouse hovers over them.

evolution-2.8.1-1.fc6
gtk2-2.10.4-4.fc6
cairo-1.2.4-1.fc6
libX11-1.0.3-4.fc6

[1] http://bugzilla.gnome.org/show_bug.cgi?id=336803#c15

I can also reproduce the misdrawn expander arrows on my Debian "Etch" box at
home (running Evolution 2.6.3), and it (mis)behaves exactly the same way for the
same folder as above.

At this point I'm not yet convinced that this is Evolution's fault.  The calls
to gtk_paint_expander() from e-cell-tree.c:draw_expander() have reasonable
inputs for both well-behaved and misbehaved expander arrows.

I also have yet to experience a crash, so I'm beginning to question whether this
bug should really be an FC6Blocker.

Matt, what are the reasonable values you are seeing going into the
gtk_paint_expander calls ?

The crash still exists in FC6; I deliberately let yum install your build and
confirmed it yesterday, before going back to my own package with the animation
disabled.

And the y=254152 value passed into gtk_paint_expander doesn't look so reasonable.

From http://bugzilla.gnome.org/show_bug.cgi?id=336803#c10:

#14 0x0edb984c in cairo_clip (cr=0xea2a2c60) at cairo.c:1715
#15 0x04ff0214 in gtk_default_draw_expander (style=0x105a4900, window=Variable
"window" is not available.
)
    at gtkstyle.c:4799
#16 0x04fea080 in IA__gtk_paint_expander (style=0x105a4900, window=0x1047b168,
    state_type=GTK_STATE_PRELIGHT, area=0xfffa549c, widget=0x10221650,
    detail=0xe56ab80 "treeview", x=375, y=254152,
    expander_style=GTK_EXPANDER_EXPANDED) at gtkstyle.c:6328
#17 0x0e5086f4 in draw_expander (ectv=Variable "ectv" is not available.
) at e-cell-tree.c:231
#18 0x0e508a34 in ect_event (ecell_view=0xe987cbe0, event=0xe9da1f28,
    model_col=5, view_col=-1, row=Variable "row" is not available.
) at e-cell-tree.c:518

Whats happening here is that this is one of the few places where ETable uses
gtk_paint functions to draw on a big window (ie one which extends beyond the X
16 bit limitation). It works fine when done inside an expose handler, since
GTK calls gdk_begin_paint for you which sets up some device offset magic to draw
to a small pixmap and copy the result back (of course, this fails when drawing
large primitives, but that is not the issue here). Apparently the drawing on the
GnomeCanvas that ETable does is not inside a gdk_begin_paint/gdk_end_paint pair.

Created attachment 137833 [details]
Failed patch (DO NOT USE)

I tried applying the attached patch where I surrounded the gdk_paint_expander()
call with gdk_window_begin_paint_rect() and gdk_window_end_paint().  The
behavior remained the same, although I'm not sure I'm using those functions
correctly.

The gtk_paint_expander() inputs I'm seeing all look something like:

Breakpoint 2, 0x0435ef46 in IA__gtk_paint_expander (style=0x998d810, 
    window=0x998e318, state_type=GTK_STATE_PRELIGHT, area=0xbfa4aef8, 
    widget=0x9378e50, detail=0x550614 "treeview", x=442, y=16530, 
    expander_style=GTK_EXPANDER_EXPANDED) at gtkstyle.c:6313
6313    {
(gdb) print *area
$6 = {x = 273, y = 16520, width = 174, height = 20}

with the following invariants:

   area->y == <0-based-row-num> * area->height
   y == area->y + area->height / 2


The last expander arrow in my folder (row 3268 of 3272) gives

Breakpoint 2, 0x0435ef46 in IA__gtk_paint_expander (style=0x998d810, 
    window=0x998e318, state_type=GTK_STATE_PRELIGHT, area=0xbfa4aef8, 
    widget=0x9378e50, detail=0x550614 "treeview", x=298, y=65370, 
    expander_style=GTK_EXPANDER_EXPANDED) at gtkstyle.c:6313
6313    {
(gdb) print *area
$4 = {x = 273, y = 65360, width = 30, height = 20}

Created attachment 153265 [details]
Bad patch

Took another crack at this tonight.

It turns out the GdkDrawable being passed up from the draw() method of
GnomeCanvasItem is a GdkPixmap, not a GdkWindow.  I believe the
begin_paint/end_paint functions Matthias was describing in comment #23 were
gdk_window_begin_paint_rect() and gdk_window_end_paint().  Is there an
equivalent buffering function for GdkPixmaps?

Strangely though, wrappering the gdk_paint_expander() call with the
aforementioned GdkWindow functions, as shown in the attached patch, did have
some positive results.	(I tried this before I realized we were getting passed
GdkPixmaps.)

I don't understand why this would make a difference, since both functions are
guarded with "g_return_if_fail (GDK_IS_WINDOW (window))", and indeed the
terminal window was spewing countless Gdk-CRITICAL warnings about failed
assertions of GDK_IS_WINDOW (window).

Nevertheless, the expander arrows responded correctly on very large folders
that previously malfunctioned.	But the background of the area being drawn was
miscolored, probably due to gdk_window_begin_paint_region():

    "A backing store (offscreen buffer) large enough to contain /region/
     will be created. The backing store will be initialized with the
     background color or background pixmap for /window/."

So, progress.  Kinda.

FWIW I disabled the workaround for this bug in my own build, and the crash seems
to have gone away. The expander animation still disappears below a certain row
in the mailbox, and the underlying cause seems to still be present -- but for
some reason it's not actually crashing like it used to.

Moving to F9Target

Lowering the severity since the crashes are no longer reproducible.

I'm still able to reproduce the misbehaving expander arrow on Evolution 2.22.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Closing this since an investigation is well underway upstream.
Please see [1] for further updates.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=336803