[Freeassociation-devel] Default value for ical_errors_are_fatal

[Patrick Ohly]

On Wed, 2008-12-17 at 06:11 +0530, Chenthill wrote:
> On Wed, 2008-12-17 at 09:07 +0100, Patrick Ohly wrote:
> > >    For the above reason, we were thinking if it can be set inside
> > > libical through a configurable option it would be better. After fixing
> > > the issues in packages which link to libecal, we will be happy to have
> > > this option enabled. At the moment considering the effort available, we
> > > may not be able to fix all the issues soon.
> > 
> > You don't have to. Just disable it in libecal and those developers who
> > don't have time to adapt won't notice any difference.
> 
> I do not want to hold the upstream merge due to this. Probably we would
> set fatal_errors in evolution, evolution-* packages and libecal.
> Announce the change in e-h list and pgo asap. If anyone is affected they
> would have enough time to set fatal_errors to 0. Since its not a very
> huge change, if there are any apps, they can make this changes fast
> enough.

Chenthill, what is the status of ical_errors_are_fatal in libecal and
Evolution general? Are errors supposed to be fatal? If so, were the
cases you mentioned above ("after fixing the issues") resolved?

I have moved SyncEvolution testing to Evolution 2.26.3 (Debian
testing/unstable) and found that EDS crashes because of
ical_errors_are_fatal != 0:

(evolution-data-server-2.26:31437): libecal-CRITICAL **: e_cal_component_get_icalcomponent: assertion `comp != NULL' failed
/tmp/buildd/libical-0.43/src/libical/icalerror.c:104: BADARG: Bad argument to function
/usr/lib/libical.so.0(ical_bt+0x1f) [0x7fe520f6addf]
/usr/lib/libical.so.0(icalerror_set_errno+0x75) [0x7fe520f6b035]
/usr/lib/evolution-data-server-1.2/extensions/libecalbackendfile.so [0x7fe51483f5cf]
/usr/lib/evolution-data-server-1.2/extensions/libecalbackendfile.so [0x7fe5148405ff]
/usr/lib/libedata-cal-1.2.so.6(e_cal_backend_sync_remove_object+0xf0) [0x7fe521b952c0]
[...]

(gdb) where
#0  0x00007fe51e10c065 in raise () from /lib/libc.so.6
#1  0x00007fe51e10f153 in abort () from /lib/libc.so.6
#2  0x00007fe51e105159 in __assert_fail () from /lib/libc.so.6
#3  0x00007fe520f6b054 in icalerror_set_errno () from /usr/lib/libical.so.0
#4  0x00007fe51483f5cf in remove_instance (cbfile=0x2117550, obj_data=0x2138460, rid=0x2147bc1 "20080413T090000Z") at e-cal-backend-file.c:2246
#5  0x00007fe5148405ff in e_cal_backend_file_remove_object (backend=<value optimized out>, cal=<value optimized out>, 
    uid=0x21285c1 "20080407T193125Z-19554-727-1-50 at gollum", rid=<value optimized out>, mod=CALOBJ_MOD_THIS, old_object=0x7fe513772cc0, 
    object=0x7fe513772cc8) at e-cal-backend-file.c:2332
#6  0x00007fe521b952c0 in e_cal_backend_sync_remove_object (backend=0x2117550, cal=0x2120860, uid=0x21285c1 "20080407T193125Z-19554-727-1-50 at gollum", 
    rid=0x2147bc1 "20080413T090000Z", mod=CALOBJ_MOD_THIS, old_object=0x7fe513772cc0, object=0x7fe513772cc8) at e-cal-backend-sync.c:296
#7  0x00007fe521b953c0 in _e_cal_backend_remove_object (backend=0x2117550, cal=0x2120860, uid=0x21285c1 "20080407T193125Z-19554-727-1-50 at gollum", 
    rid=0x2147bc1 "20080413T090000Z", mod=CALOBJ_MOD_THIS) at e-cal-backend-sync.c:765
#8  0x00007fe5200e24f0 in ORBit_small_invoke_adaptor () from /usr/lib/libORBit-2.so.0
[...]

I haven't checked where the libecal-CRITICAL comes from. I believe it is
harmless, because with ical_errors_are_fatal==0 everything works as
expected.

The impact of this problem is that SyncEvolution will not be able to
synchronize calendars correctly with 2.26.x.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly at gmx.de
http://www.estamos.de/