GNOME Bugzilla – Bug 268533
evolution-alarm-notify appears to cause an e_data_book leak in evolution-data-server
Last modified: 2013-09-10 14:03:47 UTC
Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Steps to reproduce the problem: 1. log in 2. start evolution 3. quit evolution 4. log out 5. log in at a terminal as the same user, and type "ps x" Actual Results: evolution-data-server is still around, attaching to it with gdb reveals the following: (gdb) print e_data_cal_factory_get_n_backends(e_data_cal_factory) $5 = 0 (gdb) print e_data_book_factory_get_n_backends(e_data_book_factory) $6 = 1 So we've leaked an addressbook somewhere... After some investigation, I found that if I hack away the GNOME_Evolution_Addressbook_2.0.server file, then the problem goes away. So my theory is that evolution-alarm-notify is leaking an addressbook somewhere. The persisting e_data_book has URL: file:///home/test/.evolution/addressbook/local/system I've been stepping through the shutdown of evolution-alarm-notify; it's receiving "die" signals from the session manager, and seems to be closing itself down correctly. Expected Results: evolution-data-server should have all of its backends closed down gracefully, and should quit 5 seconds later. How often does this happen? 100% Additional Information:
It appears that e_cal_backend_contacts_finalize is never called, which might explain things - this owns an EBook
In, fact e_cal_backend_finalise appears to be never called either, and this is after this: (gdb) print e_data_cal_factory_get_n_backends (e_data_cal_factory) $1 = 0 So I suspect that e_data_cal_factory is leaking references to the backends, and that the "contacts" calendar backend is holding open a connection to the local contacts backend, which is keeping e-d-s alive
i can confirm what Dave has seen, finalize mehtods of calendar backends neever gets called. We unref the backend in backend_last_client_gone_cb in e-data-cal-factory.c , but since the ref count is more than one at that point of time, dispose and finalize are not getting invoked. Since contacts calendar backend has not been cleaned up and and it is holding references to EBook which is talking to local address book backend, e-d-s never goes down. If one removes the contacts calendar group from gconf e-d-s goes down properly, so this also confirms this.
Fixed in 2.2.1, e-d-s now exits properly when all clients die. We should fixing this in a more general way though, for instance if we do a calendar backend that includes tasks, we'll have the same internal reference problem we have now.
adding perf keyword
Closing this as it has been fixed.
Having experienced e-d-s does not exit with gnome-session https://launchpad.net/bugs/90258 Could it be that this bug has reappeared?