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