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 -- [EMAIL PROTECTED] http://www.estamos.de/ _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers