Bug 660356

Created attachment 465014 [details]
File: backtrace

Thanks for a bug report. This seems to be related to the upstream bug [1]. Are those calendars accessed by CalDAV or WebCal?

[1] https://bugzilla.gnome.org/show_bug.cgi?id=628563

Thread 1 (Thread 4093):
#0  0x0000003014623dc8 in IA__g_type_check_instance (
    type_instance=<value optimized out>) at gtype.c:3806
#1  0x00000030146218f5 in IA__g_signal_emit_valist (instance=0x110c940, 
    signal_id=597, detail=0, var_args=0x7fff223d1170) at gsignal.c:2912
#2  0x00000030146225f3 in IA__g_signal_emit (instance=<value optimized out>, 
    signal_id=<value optimized out>, detail=<value optimized out>)
    at gsignal.c:3037
#3  0x000000333f43b218 in objects_added_cb (listener=<value optimized out>, 
    objects=0xb80da0, data=<value optimized out>) at e-cal-view.c:79
#4  0x000000301460bb3e in IA__g_closure_invoke (closure=0x7f0dd80021d0, 
    return_value=0x0, n_param_values=2, param_values=0x14682c0, 
    invocation_hint=0x7fff223d13a0) at gclosure.c:767
#5  0x0000003014620e23 in signal_emit_unlocked_R (node=<value optimized out>, 
    detail=0, instance=0xd54520, emission_return=0x0, 
    instance_and_params=0x14682c0) at gsignal.c:3247
#6  0x00000030146220af in IA__g_signal_emit_valist (
    instance=<value optimized out>, signal_id=<value optimized out>, 
    detail=<value optimized out>, var_args=0x7fff223d1590) at gsignal.c:2980
#7  0x00000030146225f3 in IA__g_signal_emit (instance=<value optimized out>, 
    signal_id=<value optimized out>, detail=<value optimized out>)
    at gsignal.c:3037
#8  0x000000333f43b7dd in impl_notifyObjectsAdded (
    servant=<value optimized out>, objects=<value optimized out>, 
    ev=<value optimized out>) at e-cal-view-listener.c:136
#9  0x000000301c62ff6a in ORBit_small_invoke_adaptor (
    adaptor_obj=<value optimized out>, recv_buffer=<value optimized out>, 
    m_data=<value optimized out>, data=<value optimized out>, 
    ev=<value optimized out>) at orbit-small.c:846
#10 0x000000301c63fe7d in ORBit_POAObject_handle_request (
    pobj=0x7f0dd0002a70, opname=0x7f0deb081b6c "notifyObjectsAdded", 
    ret=<value optimized out>, args=<value optimized out>, ctx=0x0, 
    recv_buffer=0x7f0debf3e150, ev=<value optimized out>) at poa.c:1357
#11 0x000000301c6404a1 in ORBit_POAObject_invoke_incoming_request (
    pobj=0x7f0dd0002a70, recv_buffer=0x7f0debf3e150, opt_ev=0x0) at poa.c:1427
#12 0x000000301c6292cc in giop_thread_queue_process (tdata=0x80e280)
    at giop.c:792
#13 0x000000301c629458 in giop_mainloop_handle_input (
    source=<value optimized out>, condition=<value optimized out>, 
    data=<value optimized out>) at giop.c:482
#14 0x0000003013a38f0e in g_main_dispatch (context=0x7e53f0) at gmain.c:1960
#15 IA__g_main_context_dispatch (context=0x7e53f0) at gmain.c:2513
#16 0x0000003013a3c938 in g_main_context_iterate (context=0x7e53f0, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2591
#17 0x0000003013a3cd55 in IA__g_main_loop_run (loop=0x855ae0) at gmain.c:2799
#18 0x0000003024e2d106 in bonobo_main () at bonobo-main.c:311
#19 0x000000000041569a in main (argc=<value optimized out>, 
    argv=<value optimized out>) at main.c:732

Oh, I'm wrong, it cannot be the upstream bug, the relevant code is there, in evolution-data-server-2.28.3-10 package.

Hi Milan,

I have have some caldav calendars configured, and some webcal calendars configured.  I will attempt to make them all caldav and see if this affects evolution's stability.

Hi Milan,

Evolution had been crashing on a daily, or more frequent basis.  At the time I had 2 caldav calendars and 3 Webcal calendars.  I converted all my webcal calendar references to caldav calendars (OK, I disabled the webcal entries and added caldav entries).  Evolution hasn't crashed in the past week!

So, the problem likely involves webcal calendars.

As an experiment, I switched all my calendars to Web calendars.  I will see if this affects Evolution stability.  I am trying to differentiate between problems with Web Calendars, and problems when using both Web Calendars and CalDav calendars (for different calendars).

By the way, when I had both types of calendars, I found that Evolution crashed shortly after it received quite a bit of traffic from the calendar server - even if Evolution had been running for a long time.  Unfortunately the contents traffic is encrypted, so Wireshark won't decode it.

Now that I am using only Webcal calendars, I am getting frequent evolution or evolution-data-server crashes.  Looks like Caldav works just fine for me.

I found that evolution crashes when I have a meeting scheduled at that time in a webcal calendar.

I did a little progress on a similar issue in an upstream bug [1], which is not fixing the issue completely, but it avoids unnecessary updates of already opened web calendars. We may be able to reuse patch from there, together with a fix from bug [2].

[1] https://bugzilla.gnome.org/show_bug.cgi?id=420813
[2] https://bugzilla.gnome.org/show_bug.cgi?id=630265

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

*** Bug 663776 has been marked as a duplicate of this bug. ***

I'm on this, thus reopening and moving to evolution-data-server.

Created attachment 473894 [details]
eds patch

for evolution-data-server;

Fixes the above issue, and incorporates changes from the upstream bugs, so the calendar view is not flashing so much when updating content of a webcal in the data server.

I built a package which has the patch for this included. Please try with evolution-data-server-2.28.3-13.el6. Thanks in advance.

https://brewweb.devel.redhat.com/taskinfo?taskID=3040170

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0713.html