The program 'evolution' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 415515 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.)
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