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

[Patrick Ohly <Patrick Ohly gmx de>]

On Mo, 2006-10-16 at 19:21 +0200, Patrick Ohly wrote:
> > >       * Is someone running Evolution and in particular the
> Evolution
> > >         data server under valgrind as part of release testing or
> regular
> > >         quality assurance?
> > 
> > I know there is performance work in relation with evolution for suse
> > installations. For general quality assurance there are not enough
> > routines in place. I know it's on the todo list of the developers.
> > When it comes to valgrind testing, evolution becomes quite slow so
> > patience is a must.
> 
> One can test e-d-s non-interactively, which is what I am doing at the
> moment. Okay, if no-one else is working on it I'll have to see what I
> can find out on my own. 

I found out what the problem is, see
http://bugzilla.gnome.org/show_bug.cgi?id=363102

The memory access error is caused by two threads operating on the same
data: the main one is writing the calendar to disk in the idle loop, the
other is processing a CORBA request to delete components of that same
calendar.

There is a mutex, but none of the CORBA implementation functions lock
it. Any suggestions how to fix this? As I said in that issue, several
solutions come to mind:
- lock the mutex inside the high-level e_cal_backend_* functions
- lock the mutex inside the low-level functions like remove_component
- serialize idle saving and CORBA requests by having the saving executed as
  a CORBA call (not sure exactly how that could be done...)

Of course, one could always disable the writing of the calendar data in
the idle loop, but without some other means to flush the data it would
be very dangerous to wait until an orderly shutdown of the E-D-S
process.

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