GNOME Bugzilla – Bug 693461
[regression] Book client not freed on export end
Last modified: 2013-09-13 01:07:46 UTC
Created attachment 235576 [details] test patch Apply the attached patch to evolution, compile the folder and then run evolution-addressbook-export from there. Its end, when it's done with export, should be like this: object_gone_cb: 0x7fb9bc004690 But the current code is not freeing the book client properly, it lefts factory with stale objects. This works as expected in 3.6, hence it's a regression since recent changes.
It's possible I introduced a reference leak here. I did kind of rush through this tool since no one uses it.
(In reply to comment #1) > It's possible I introduced a reference leak here. Right, you did. > I did kind of rush through this tool since no one uses it. And no, it's not about that tool, I only picked an existing and simple code to show the issue. That's why gnome-3-6 branch does the right thing, but the master branch, after your changes, not. The issue is not with book only, it's with the calendar as well.
As suspected, because the program does not use a main loop there were some undispatched event sources in the default main loop context. These event sources -- the change notifications you claim don't happen -- hold references on the EBookClient. Just need to flush the main loop context before exiting and your test patch will show the EBookClient is finalized. Fixed in: http://git.gnome.org/browse/evolution/commit/?id=c10031f0675a3bb353cfe9a8bc244aed08194eb8
OK, you found the reason about main contexts, the limitation you added within your EClient DBus API changes. It's a very wrong limitation, and what you did in this commit (why do not you name the bug in the commit? I use to search for bugs this way, and it proved to be useful, not only expected by the coders to write bug references to commits, if there are any) is just a workaround for a more sever regression you introduced. I'd like to see a real fix for that regression, but we can talk about that within bug #693464.