[Evolution-hackers] automated testing of Evolution data server with SyncEvolution

[Patrick Ohly <Patrick Ohly gmx de>]

Hi all,

I have not mentioned it on this list before, so before I come to the
real reason for this email let me introduce it briefly: SyncEvolution[1]
is a SyncML client that I wrote to synchronize address books, calendars
and tasks list between Evolution and mobile devices or Evolution
instances on different computers. In contrast to other approaches it
requires a SyncML servers, but there are free ones available that one
can install locally or (the simpler solution) one can synchronize with
several web services. At this time it is a command line tool, but it
could be turned into a plugin easily.

At this time I consider getting (and keeping) it stable more important
than the GUI, so I invested a lot of work into automated regression
testing and run nightly tests with several different Evolution versions,
compiled with Garnome.

This automated testing suffers a bit from instabilities of the Evolution
data server and when adding Gnome 2.8 to the testing I also found a
regression in the handling of vcards. I have reported that in [2] a
month ago, but the only activity that I have seen to fix this is that
Andre confirmed the problem.

I can try to help but my time is limited, so let me ask a few questions
first:
      * Is someone going to take care of the reported regression or do
        you need a patch to fix it? Whoever changed the code between 2.6
        and 2.8 should be in a better position to fix it, so I am a bit
        reluctant to investigate further in code that I don't know.
      * Is someone running Evolution and in particular the Evolution
        data server under valgrind as part of release testing or regular
        quality assurance?
      * Which branches are still maintained? At the moment Debian still
        has 2.6 in testing and unstable; if there is a chance to still
        get bug fixes into that version, I'd concentrate on that first
        instead of the more recent 2.8.

To nail down the crashes I have started to run the data server under
valgrind and it finds some issues. One is a jump which depends on an
uninitialized value. This is inside e_data_book_factory_activate() and
occurs deep down inside libbonobo; it may be a false positive and
doesn't seem to cause problems. The other, fatal one is a read of
previously freed memory inside libecal - see [3] for a log where this
occurs in 2.6 and [4] for 2.8. Here's an excerpt:

==31437== Invalid read of size 4
==31437==    at 0x43184F6: icalproperty_as_ical_string (icalproperty.c:444)
==31437==    by 0x43102D7: icalcomponent_as_ical_string (icalcomponent.c:322)
==31437==    by 0x431032F: icalcomponent_as_ical_string (icalcomponent.c:334)
==31437==    by 0x4F6CD75: save_file_when_idle (e-cal-backend-file.c:176)
==31437==    by 0x495A9A2: g_idle_dispatch (gmain.c:3926)
==31437==    by 0x4957919: g_main_dispatch (gmain.c:2045)
==31437==    by 0x49589B7: g_main_context_dispatch (gmain.c:2596)
==31437==    by 0x4958CEF: g_main_context_iterate (gmain.c:2677)
==31437==    by 0x4959292: g_main_loop_run (gmain.c:2881)
==31437==    by 0x4489BF7: bonobo_main (bonobo-main.c:311)
==31437==    by 0x804BDA6: main (server.c:393)
==31437==  Address 0x6C9D7F0 is 8 bytes inside a block of size 32 free'd
==31437==    at 0x401C37E: free (vg_replace_malloc.c:233)
==31437==    by 0x4318218: icalproperty_free (icalproperty.c:254)
==31437==    by 0x4310103: icalcomponent_free (icalcomponent.c:240)
==31437==    by 0x42EA4EF: free_icalcomponent (e-cal-component.c:300)
==31437==    by 0x42EA577: e_cal_component_finalize (e-cal-component.c:389)
==31437==    by 0x48D9083: g_object_unref (gobject.c:1785)
==31437==    by 0x4F6CC2F: free_object_data (e-cal-backend-file.c:114)
==31437==    by 0x494B5CB: g_hash_node_destroy (ghash.c:768)
==31437==    by 0x494AD7C: g_hash_table_remove (ghash.c:433)
==31437==    by 0x4F6D90D: remove_component (e-cal-backend-file.c:582)
==31437==    by 0x4F70A08: e_cal_backend_file_remove_object (e-cal-backend-file.c:2150)
==31437==    by 0x42A7262: e_cal_backend_sync_remove_object (e-cal-backend-sync.c:295)
==31437==    by 0x42A8857: _e_cal_backend_remove_object (e-cal-backend-sync.c:764)
==31437==    by 0x42A24B4: e_cal_backend_remove_object (e-cal-backend.c:937)
==31437==    by 0x42A9AF0: impl_Cal_removeObject (e-data-cal.c:356)
==31437==    by 0x429BBD2: _ORBIT_skel_small_GNOME_Evolution_Calendar_Cal_removeObject (Evolution-DataServer-Calendar-common.c:120)
==31437==    by 0x48A1AB6: ORBit_POAObject_invoke (poa.c:1142)
==31437==    by 0x48A6B84: ORBit_OAObject_invoke (orbit-adaptor.c:336)
==31437==    by 0x4890624: ORBit_small_invoke_adaptor (orbit-small.c:835)
==31437==    by 0x48A1EA7: ORBit_POAObject_handle_request (poa.c:1351)
icalproperty.c:451: Got a property of an unknown kind.

Does that look familiar to anyone?

[1] http://www.estamos.de/projects/SyncML/
[2] http://bugzilla.gnome.org/show_bug.cgi?id=356176
[3] http://www.estamos.de/runtests/2006-10-14-17-00/0.4-garnome-2.14.3/5-scheduleworld/dataserver.log.gz
[4] http://www.estamos.de/runtests/2006-10-14-17-00/0.4-2.18.0/5-scheduleworld/dataserver.log.gz

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