After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 420167 - e-d-s does not exit with gnome-session
e-d-s does not exit with gnome-session
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
1.10.x (obsolete)
Other Linux
: Normal major
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
: 468090 470430 563100 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-03-19 16:08 UTC by Sebastien Bacher
Modified: 2010-01-29 00:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
ps axu | grep USERNAME (988 bytes, text/plain)
2007-06-29 18:22 UTC, elias
  Details
Patch for e-d-s-1.10.2 termination failure (894 bytes, patch)
2007-07-19 17:29 UTC, John B.
reviewed Details | Review
proposed eds patch (ref/unref only) (1.52 KB, patch)
2007-10-05 08:34 UTC, Milan Crha
none Details | Review
proposed eds patch (ref/unref only) ][ (3.91 KB, patch)
2007-10-05 11:28 UTC, Milan Crha
committed Details | Review

Description Sebastien Bacher 2007-03-19 16:08:34 UTC
The bug has been opened on https://launchpad.net/bugs/90258

"Binary package hint: evolution-data-server

E-d-s stays active after session logout, breaking e.g. gnome-settings-daemon after re-login without killing e-d-s explicitly on console. Encountered this Problem first time in Edgy, after updating to Feisty today nothing changed.

Update: The breakage of things after re-login is related to a still running bonobo-activation-server, which seems to be caused by e-d-s (killing e-d-s kills bonobo-activation-server, too). Any hint how to debug - or even better - how to fix this?
...
http://librarian.launchpad.net/6823999/eds-running.log.gz
Strace output

Here is a strace-output. Strace was attached to an running e-d-s process, which was started via evolution (from office-menu). It started showing calendar. Then attached strace to pid, then opened evo back with calendar component, taking a look to the next month, then closing and exiting session. Afterwards I waited a bit more than a minute and then killed e-d-s, which was still running after logout.
...
http://librarian.launchpad.net/6839112/eds-started-from-terminal.txt.gz
Strace output when e-d-s is started from terminal

I'll try it later, but I'm not really sure how to use gdb on a process that is not really crashing - it simply stays active, in theory (if it would not keep open bonobo-activation-server what does harm to some applets (gswitchit etc) it could be re-used after re-login.

The former strace-output seems not to be the best for finding out what is going wrong, starting e-d-s from terminal with strace directly I got some error messages, which seem to be a bit more helpful.

---
Especially the following lines seem to be interesting:
09:21:33.882038 write(2, "\n(evolution-data-server:7683): G"..., 112
(evolution-data-server:7683): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
) = 112
09:21:33.882138 write(2, "\n(evolution-data-server:7683): l"..., 148
(evolution-data-server:7683): libedata-cal-CRITICAL **: e_cal_backend_internal_get_default_timezone: assertion `E_IS_CAL_BACKEND (backend)' failed
) = 148
09:21:33.882250 write(2, "\n(evolution-data-server:7683): G"..., 113
(evolution-data-server:7683): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
) = 113
---

Please note: After setting up evolution on a clean account, everything went well untill I set up birthday-calendar events. Same seems to be true when tasks or other events are added.
...


After some research, I found http://bugzilla.gnome.org/show_bug.cgi?id=268533, it seems a bit similar to this (although it is marked fixed for 1,5 years now).

attaching gdb to the running e-d-s-process, I get the following:

---
(gdb) print e_data_cal_factory_get_n_backends(e_data_cal_factory)
$1 = 0
(gdb) print e_data_book_factory_get_n_backends(e_data_book_factory)
$2 = 3
---
Note: I have configured 3 Adress-Books on the current account, all seem to be kept open by something even after logout from session.
...
I found an ugly workaround. When I move the file /usr/lib/evolution-data-server-1.2/extensions/libecalbackendcontacts.so out of the way, e-d-s and b-a-s are shutting down properly. Something in this backend seems to be broken."
Comment 1 Frederic Crozat 2007-03-20 14:46:42 UTC
we are seeing same issue on mandriva cooker
Comment 2 elias 2007-04-28 07:43:02 UTC
This bug is rather severe as it breaks things after relogin. Now in LTSP environments relogins is what you got 1000 times a day. So you end up with tons of orphaned processes and the desktop not working for the users.

In the light of this, please increase the importance of this bug and get a fix out there soon as it renders gnome 2.18 unusable for LTSP environments.
Comment 3 Reinout van Schouwen 2007-04-29 20:43:20 UTC
setting severity: major.
Comment 4 Cesare Tirabassi 2007-06-29 10:12:48 UTC
Isn't this closely related to this:

http://bugzilla.gnome.org/show_bug.cgi?id=152907
Comment 5 elias 2007-06-29 18:22:50 UTC
Created attachment 90890 [details]
ps axu | grep USERNAME

esd stays active too
Anyway, I hope esd will be discarded in favor of pulseaudio soon!
Comment 6 elias 2007-06-29 18:25:47 UTC
Here is a list of all processes which stay active after logout on my Ubuntu Feisty installation:

elias     5751  0.0  0.2  39700  3264 ?        Ssl  19:53   0:00 /usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=16
elias     6051  0.0  0.6  68160  9892 ?        Sl   19:54   0:00 /usr/lib/evolution/evolution-data-server-1.10 --oaf-activate-iid=OAFIID:GNOME_Evolution_Data
Server_BookFactory:1.2 --oaf-ior-fd=43
elias     7084  0.0  0.0   1712   468 ?        Ss   20:17   0:00 /bin/sh -c /usr/bin/esd -terminate -nobeeps -as 1 -spawnfd 29
elias     7085  0.0  0.0   3316  1512 ?        S    20:17   0:00 /usr/bin/esd -terminate -nobeeps -as 1 -spawnfd 29
elias     7093  0.0  0.1   4776  2220 ?        S    20:17   0:00 /usr/lib/libgconf2-4/gconfd-2 14

Most processes started by the gnome-session-manager get closed however. Therefore, I would not think this is related to the bug mentioned above. But what do I know.
Comment 7 elias 2007-06-29 18:26:47 UTC
Please have a look at these two bug reports for additional information:
https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/90258
https://bugs.launchpad.net/ubuntu/+source/libbonobo/+bug/90923
Comment 8 Gert Kulyk 2007-07-07 15:01:58 UTC
The problem is, that somehow the addressbooks are kept open. It seems like the finalize-function does not unref/close/free (?) the referenced books properly.

The following is called in e_cal_backend_contacts_finalize:

g_hash_table_destroy (priv->addressbooks);
g_hash_table_destroy (priv->tracked_contacts);
g_hash_table_destroy (priv->zones);

I'm not an experienced programmer, and not familiar with e-d-s and glib stuff, but I've compared the finalize-functions of different evolution-backends. evolution-jescs (calendar/cal-backend-wcap.c) e.g. uses such GHashTables, too, but there the finalize_handler for a GHashTable looks like this:

in cal_backend_wcap_finalize you'll find:

if (priv->objects) {
 g_hash_table_foreach (priv->objects, (GHFunc) destroy_object_hash, NULL);
 g_hash_table_destroy (priv->objects);
 priv->objects = NULL;
}

where destroy_object_hash-function looks like this:

static void
destroy_object_hash (gpointer key, gpointer value, gpointer user_data)
{
	g_free (key);
	g_object_unref (G_OBJECT (value));
}

I may be wrong, but is it possible that a simple "g_hash_table_destroy" is not enough to close all addressbooks?
Comment 9 Gert Kulyk 2007-07-11 12:09:30 UTC
Hmpf, sorry for the above nonsense - the mentioned part of evolution-jescs is using g_hash_table_new () instead of g_has_table_new_full () (like e-cal-backend-contacts.c does) for creation of the given GHashTables. 

But this leads me to the assumption, that one of the callback-functions - either "book_record_free ()" or "contact_record_free ()" - is not cleaning up the whole show. Either one of the given callback-function is missing something, or the finalize-function has to be extended, so that the address-books are closed down with the rest of e-d-s, too. Any hints, what exactly this may be?
Comment 10 John B. 2007-07-19 17:29:17 UTC
Created attachment 91997 [details] [review]
Patch for e-d-s-1.10.2 termination failure

Free subcomponents of static timezone struct
Comment 11 John B. 2007-07-19 17:33:56 UTC
I've had this problem on Fedora 7 with e-d-s-1.10.2, but didn't have it on Fedora Core 6 with e-d-s-1.8.3, so I compared the two, and noticed in calender/backends/contacts that there was a single fix to e-cal-backend-contacts.c that looked like it was trying not to free a static structure.  I think the problem with the fix is that the static structure has dynamically allocated components that thus weren't getting freed, and those seem for me to have been the cause of the failure to terminated.  I adjust the fix to free the components but not the static struct itself (there was already a mechanism in place for that).
Comment 12 John B. 2007-07-19 17:44:43 UTC
Sorry for the typos...

I meant to mention that I don't consider my patch a complete fix - it's just a workaround I think others having the problem might try.  I wouldn't be surprised if this comes up again somewhere else involving bonobo-activation-server.
Comment 13 Chenthill P 2007-08-09 11:28:51 UTC
The utc timezone is not freed since its a static struct defined
as below,
static icaltimezone utc_timezone = { 0, 0, 0, 0, 0, 0, 0, 0, 0 };

And the get_utc_timezone returns the address of that structure 
return &utc_timezone;

If you pass 0 to icaltimezone_free, it would try to free the internal elements in icaltimezone structure and reintialize the values. But since all the internal elements are just 0 in this case, it doesnt make much sense to call it for utc timezone.
Comment 14 John 2007-09-10 01:17:29 UTC
I've been struggling with vnc, ltsp and b-a-s on RedHat's Fedora. Could these bugs be related? A number of gnome panel apps crash in follow-on sessions.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=245525">RH bug 245525</a>
Comment 15 Frederic Crozat 2007-10-03 17:08:57 UTC
I've done some research on this bug :

e-d-s not exiting is caused by contacts (ie birthday) backend of calendar component.

When contacts backend is disabled, e-d-s is exiting correctly.

You get the broken behaviour with either alarm-notify, gnome-panel clock applet (after opening it one time) or dates (easier to reproduce with date).

the call to e_book_new (sources, NULL) in e-cal-backend-contacts.c (even, for test purpose, followed by a g_object_unref (book) and return NULL in book_record_new is causing the component leakage.

It seems the leak is in addressbook component.
Comment 16 John B. 2007-10-03 18:02:41 UTC
(In reply to comment #15)
> I've done some research on this bug :
> 
> e-d-s not exiting is caused by contacts (ie birthday) backend of calendar
> component.
> 
> When contacts backend is disabled, e-d-s is exiting correctly.
> 
> You get the broken behaviour with either alarm-notify, gnome-panel clock applet
> (after opening it one time) or dates (easier to reproduce with date).
> 
> the call to e_book_new (sources, NULL) in e-cal-backend-contacts.c (even, for
> test purpose, followed by a g_object_unref (book) and return NULL in
> book_record_new is causing the component leakage.
> 
> It seems the leak is in addressbook component.
> 

Read my comment (#11).  I already found a leak in e-cal-backend-contacts, and submitted a patch for it.

But I think the problem is bigger than just this leak.

Try the patch; see it it helps; go from there...
Comment 17 Frederic Crozat 2007-10-04 12:22:12 UTC
John, your patch fixes a memory leak, not a reference leak. And this bug is caused by a reference leak and won't be fixed by plugging memory leaks (unless they are coupled with ref leak :)
Comment 18 Milan Crha 2007-10-05 08:34:57 UTC
Created attachment 96682 [details] [review]
proposed eds patch (ref/unref only)

for evolution-data-server;

Here's a patch for ref/unref part of this bug *only*. I tested it with evolution-alarm-notify and when applied then eds closes a bit after alarm-notify is closed.
Comment 19 Milan Crha 2007-10-05 11:28:08 UTC
Created attachment 96692 [details] [review]
proposed eds patch (ref/unref only) ][

for evolution-data-server;

My first patch worked only when there was at least one contact with birthday or anniversary. This one seems like working even without any contact with birthday or anniversary.
Comment 20 John B. 2007-10-05 14:17:01 UTC
(In reply to comment #17)
> John, your patch fixes a memory leak, not a reference leak. And this bug is
> caused by a reference leak and won't be fixed by plugging memory leaks (unless
> they are coupled with ref leak :)
> 

I didn't expect it would fix the problem entirely - I said as much; and I didn't
classify the leak(s) it fixes.  But it did help in my case.  For a while I wasn't
having the problem at all, though it's back now (on Fedora 7).

I'm not an Evolution developer; I'm a Fedora user.

I don't even like Evolution, but this stuff is so wired into GNOME that I can't
easily get rid of it (I've tried).

Milan, I'll try your patch... 8^)
Comment 21 Gert Kulyk 2007-10-05 14:24:29 UTC
E-D-S after applying commited patch seems to exit gracefully, tested with evo 2.12 and eds 1.12.
Comment 22 Frederic Crozat 2007-10-05 17:50:13 UTC
I can confirm Milan latest patch fixes the issues when no contact has birthday / anniversary set or if one has (sorry Milan for false tests this morning, it seems my test system was a little too much instable).
Comment 23 Frederic Crozat 2007-10-10 17:32:35 UTC
Would it be possible to get a review of Milan patch ? This bug is quite visible on a lot of distributions and it would be great to have it fixed for e-d-s 1.12.1
Comment 24 John B. 2007-10-10 19:09:15 UTC
I meant to reply that it seems to be working for me also, Milan & Frederic, but I haven't agressively tested it (nor am I really equipped to do so), and I only have it applied to 1.10.3.1, which is Fedora 7's currently released version.  I'm not involved with the maintenance of this package on Fedora or elsewhere.

I would mention, though, since I saw this early, that a quick login/logout doesn't tickle the bug; for me, it takes about a minute after login for e-d-s to start.

Thanks for your good efforts, Milan (and you too, Frederic). 8^)
Comment 25 Srinivasa Ragavan 2007-10-11 05:58:11 UTC
book->priv->corba_book has to be initialized to CORBA_OBJECT_NIL and not NULL.
I can see that it works fine for me also. I think we can push this to head and stable then. 

Comment 26 Milan Crha 2007-10-11 15:09:41 UTC
Committed to trunk. Committed revision 8110.
Committed to stable. Committed revision 8111.

Fixed my fault. I kept this opened because of the first patch from comment #10, which is marked as 'Reviewed' right now, even I think it doesn't make sense to clear that data, so it should be 'rejected' instead, but I'm not sure about it.
Comment 27 Brian Beardall 2007-10-19 19:48:49 UTC
Tihs bug is still occurring for me on e-d-s 1.12.1. This bug has been occurring for me since gnome 2.16 when I filled in the contacts, appointments. For a while I've been moving the libecalbackendcontacts.so to roots home so I have a backup of the current version. 
Comment 28 Milan Crha 2007-10-22 09:48:32 UTC
Is it possible that you've there some kind of mess with those backuped files? May be better, same as Frederic explained above, can you provide some additional information how to reproduce it? I can imagine that evolution crashed and then the eds will not be closed properly, because crashed evolution kept reference to it. Also, when you run evolution --force-shutdown then the bonobo server will still run, because killed eds/evo will not unref what has referenced. I'm just guessing...
Comment 29 John B. 2007-10-22 17:03:40 UTC
It's happening again for me now; there's a stale bonobo-activation-server hanging
around after logout, but no e-d-s.
Comment 30 Milan Crha 2007-10-23 05:38:16 UTC
ok, if bonobo stayed opened, then use bug 303083, instead of this, please.
Comment 31 Milan Crha 2007-10-23 05:42:06 UTC
(I'm sorry for spam, I forget to keep this opened because of patch from 2007-07-19.)
Comment 32 Milan Crha 2008-02-27 09:43:52 UTC
*** Bug 470430 has been marked as a duplicate of this bug. ***
Comment 33 Suman Manjunath 2008-03-06 04:30:33 UTC
*** Bug 468090 has been marked as a duplicate of this bug. ***
Comment 34 Nicolò Chieffo 2008-03-27 18:10:09 UTC
Do you still have this problem? can we close the bug?
Comment 35 Shuai Liu 2008-09-03 08:04:32 UTC
Now, I can reproduce this bug at ubuntu 8.10 and solaris 11.
After I log out and log in many times, there will be several evolution-data-server processes.
Now I log on as user liushuai, and I can see the process here:

liushuai@golf:~$ ps -ef | grep evolution-data-server
liushuai  3290     1  0 11:09 ?        00:00:00 /usr/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=30
test100   5111     1  0 15:28 ?        00:00:00 /usr/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=23
liushuai  6725     1  0 15:35 ?        00:00:00 /usr/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=27
liushuai  6900  6762  0 16:04 pts/0    00:00:00 grep evolution-data-server
Comment 36 Shuai Liu 2008-09-03 08:05:07 UTC
By the way, I use evolution and evolution-data-server 2.23.91.
Comment 37 Pacho Ramos 2009-10-22 18:48:43 UTC
I still suffer this with 2.26 under Gentoo
Comment 38 Pacho Ramos 2009-10-27 09:24:07 UTC
The problem seems to be related with evolution-alarm-notify being still alive when I logout from my gnome-session:
1. Run evolution
2. Close it
3.  $ ps axu | grep evo
pacho     8378  0.0  0.9 334404 20516 ?        Sl   10:20   0:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=23
pacho     8410  0.0  1.0 342908 22588 ?        Sl   10:20   0:00 /usr/libexec/evolution/2.26/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.26 --oaf-ior-fd=25
pacho     8900  0.0  0.0   9976   848 pts/0    R+   10:22   0:00 grep --colour=auto evo

4. Now, logout

---> evolution-alarm-notify is killed but evolution-data-server keeps running forever

Now, try the following:
1. Run evolution
2. Close it
3. kill evolution-alarm-notify
4. If you wait a bit, e-d-s exits itself, if you don't wait and logout directly, it's also properly killed
Comment 39 Milan Crha 2009-10-27 09:35:01 UTC
*** Bug 563100 has been marked as a duplicate of this bug. ***
Comment 40 Igor 2009-11-18 22:53:59 UTC
Pacho Ramos, killing evolution-alarm-notify does not help, esp. if you click on the clock applet. It triggers evolution-data-server to be launched to mark events from the evolution calendar.

The e.d.s remains active even after the user logs out.

To reproduce:

1. log in
2. click on the calendar applet
3. logout
4. check processes, there should be an e.d.s still running

Performing the above steps afain makes another e.d.s to be running and so on.
Comment 41 Ira Moss 2010-01-28 23:48:59 UTC
I too have this issue, and have had it for a long time.

If I disable all the the alarm/notify functions that I can find.  Still upon exit, I get these processes...  Here in this snippit, I've got myself, and one user who has actually logged out of their session all together....

This makes a MESS for NFS mounts!

 $ ps -ef | grep evolu
imoss     2016     1  0 16:10 ?        00:00:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=28
imoss     2038     1  0 16:10 ?        00:00:00 /usr/libexec/evolution/2.26/evolution-alarm-notify --oaf-activate-iid=OAFIID:GNOME_Evolution_Calendar_AlarmNotify_Factory:2.26 --oaf-ior-fd=29
imoss     2925  2914  0 16:46 pts/1    00:00:00 grep --colour=auto evolu
bdm       8416     1  0 06:55 ?        00:00:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=26
bdm       9371     1  0 07:57 ?        00:00:00 /usr/libexec/evolution-data-server-2.26 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2 --oaf-ior-fd=20


Is there any progress on this issue at all?
Comment 42 Matthew Barnes 2010-01-29 00:16:09 UTC
Yes, it's already fixed in 2.29 by dropping Bonobo.  Closing as fixed.