On Sat, 2013-02-23 at 23:38 +0900, Tristan wrote: > This indicates that somewhere, in the client or server, we > are leaking references to the GDBusConnections. I've tested > this in raw GIO (and added a test case there) to ensure it > is indeed possible to stop/start the GTestDBus between tests, > the problem is clearly an ugly bug to be fixed in EDS.
I suspect this might be related to the factory proxy object that we create in the background and leave lying around as a global variable. We could try letting EBookClient create its own EDBusAddressBookFactory proxy, call its OpenAddressBook method, and then immediately destroy it. That would simplify the code, eliminate the global variable, and quite possibly fix the GDBusConnection leak (if my guess is right). I'll prototype this for 3.9. I think I've pulled enough D-Bus stunts for one release already. > This is due to a race condition in e_client_remove_sync(), > this call is made at the end of a test case.. which results > in the ESource being removed from the ESourceRegistry server. > > What happens when the cache-reaper module is loaded, is that > the 'test-address-book' source is removed /some time after/ > e_client_remove_sync() completes... sometimes this happens > right in the middle of the following test case. Probably another side effect of (A). In the interim, it might help if the ESource's unique ID were actually unique for each test case, instead of a static ID for all cases. Instead of "test-address-book" use "test-address-book-N" where 'N' is the test case number or some other increasing integer. Matthew Barnes _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers