Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
Tor,
Please commit the patch to HEAD as well as the stable branch. The
change looks fine to me. I will also get the unregister action tested
in the regular builds on the branches and perhaps in MacOS (I do not
know if it matters, but anyway!) as a routine but I do not expect any
surprises.
Thanks,
Harish
On Sat, 2006-06-17 at 02:23 +0300, Tor Lillqvist wrote:
> lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
>
> > If my analysis is correct, this means that attempting to do a CORBA
> > object unregistration in the GObject finalize method is too late, isn't
> > it?
>
> I tested by applying this simple patch to e-shell.c, moving the
> bonobo_activation_active_server_unregister() call from impl_finalize()
> to notify_no_windows_left_idle_cb():
>
> Index: shell/e-shell.c
> ===
> RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
> retrieving revision 1.272
> diff -p -u -r1.272 e-shell.c
> --- shell/e-shell.c 30 Jan 2006 11:49:53 - 1.272
> +++ shell/e-shell.c 16 Jun 2006 23:17:50 -
> @@ -360,13 +360,18 @@ static gboolean
> notify_no_windows_left_idle_cb (void *data)
> {
> EShell *shell;
> + EShellPrivate *priv;
>
> shell = E_SHELL (data);
> + priv = shell->priv;
>
> set_interactive (shell, FALSE);
>
> g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
>
> + if (priv->iid != NULL)
> + bonobo_activation_active_server_unregister (priv->iid,
> +
> bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
> bonobo_object_unref (BONOBO_OBJECT (shell));
>
> return FALSE;
> @@ -467,10 +472,6 @@ impl_finalize (GObject *object)
>
> shell = E_SHELL (object);
> priv = shell->priv;
> -
> - if (priv->iid != NULL)
> - bonobo_activation_active_server_unregister (priv->iid,
> -
> bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
>
> e_free_string_list (priv->crash_type_names);
>
> And lo and behold, it works! Now the ESHell gets unregistered, and when
> starting Evolution again it manages to register its EShell and contact
> the already running e-d-s etc.
>
> OK to apply this patch to HEAD and stable? ChangeLog entry:
>
> 2006-06-17 Tor Lillqvist <[EMAIL PROTECTED]>
>
> * e-shell.c (impl_finalize): Don't call
> bonobo_activation_active_server_unregister() here, it's too late,
> the EShell Bonobo object has already been deactivated and its
> associated CORBA object is NULL.
> (notify_no_windows_left_idle_cb): Instead, call
> bonobo_activation_active_server_unregister() here, when the EShell
> Bonobo object is still fully active.
>
>
> I should still of course also investigate why the other (unknown)
> mechanism which causes unregistration to happen anyway on Unix doesn't
> work on Windows...
>
> --tml
>
>
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
ah, okay. Jeff On Mon, 2006-06-19 at 17:03 +0300, Tor Lillqvist wrote: > må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast: > > Is there a ::destroy() method on the EShell object (like GtkWidgets)? > > Perhaps it would be better to unregister there rather than in an idle > > cb? My concern is that in the idle cb, there may still be a race? > > Nah... The impl_finalize() where the unregistration is currently done > (but doesn't work) is called from the same > notify_no_windows_left_idle_cb() function (through > bonobo_object_unref()). > > --tml > > -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast: > Is there a ::destroy() method on the EShell object (like GtkWidgets)? > Perhaps it would be better to unregister there rather than in an idle > cb? My concern is that in the idle cb, there may still be a race? Nah... The impl_finalize() where the unregistration is currently done (but doesn't work) is called from the same notify_no_windows_left_idle_cb() function (through bonobo_object_unref()). --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
Is there a ::destroy() method on the EShell object (like GtkWidgets)?
Perhaps it would be better to unregister there rather than in an idle
cb? My concern is that in the idle cb, there may still be a race? Even
if not, tho, I feel it would be cleaner to unregister in a ::destroy()
if that's a possibility.
Jeff
On Sat, 2006-06-17 at 02:23 +0300, Tor Lillqvist wrote:
> lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
>
> > If my analysis is correct, this means that attempting to do a CORBA
> > object unregistration in the GObject finalize method is too late, isn't
> > it?
>
> I tested by applying this simple patch to e-shell.c, moving the
> bonobo_activation_active_server_unregister() call from impl_finalize()
> to notify_no_windows_left_idle_cb():
>
> Index: shell/e-shell.c
> ===
> RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
> retrieving revision 1.272
> diff -p -u -r1.272 e-shell.c
> --- shell/e-shell.c 30 Jan 2006 11:49:53 - 1.272
> +++ shell/e-shell.c 16 Jun 2006 23:17:50 -
> @@ -360,13 +360,18 @@ static gboolean
> notify_no_windows_left_idle_cb (void *data)
> {
> EShell *shell;
> + EShellPrivate *priv;
>
> shell = E_SHELL (data);
> + priv = shell->priv;
>
> set_interactive (shell, FALSE);
>
> g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
>
> + if (priv->iid != NULL)
> + bonobo_activation_active_server_unregister (priv->iid,
> +
> bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
> bonobo_object_unref (BONOBO_OBJECT (shell));
>
> return FALSE;
> @@ -467,10 +472,6 @@ impl_finalize (GObject *object)
>
> shell = E_SHELL (object);
> priv = shell->priv;
> -
> - if (priv->iid != NULL)
> - bonobo_activation_active_server_unregister (priv->iid,
> -
> bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
>
> e_free_string_list (priv->crash_type_names);
>
> And lo and behold, it works! Now the ESHell gets unregistered, and when
> starting Evolution again it manages to register its EShell and contact
> the already running e-d-s etc.
>
> OK to apply this patch to HEAD and stable? ChangeLog entry:
>
> 2006-06-17 Tor Lillqvist <[EMAIL PROTECTED]>
>
> * e-shell.c (impl_finalize): Don't call
> bonobo_activation_active_server_unregister() here, it's too late,
> the EShell Bonobo object has already been deactivated and its
> associated CORBA object is NULL.
> (notify_no_windows_left_idle_cb): Instead, call
> bonobo_activation_active_server_unregister() here, when the EShell
> Bonobo object is still fully active.
>
>
> I should still of course also investigate why the other (unknown)
> mechanism which causes unregistration to happen anyway on Unix doesn't
> work on Windows...
>
> --tml
>
>
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
--
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED] - www.novell.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
On Mon, 2006-06-19 at 00:18 +0300, Tor Lillqvist wrote: > I think I have a good guess now: The problem is that all sockets by > default are inherited by child processes in Windows. (Like file > descriptors in Unix.) Ah - we had some wonderful b-a-s bugs for the few sockets we didn't CLOEXEC in the past. Of course, we still allowed b-a-s clients to inherit stdout/in/err (at least, until the g_spawn rework (?)) - but that is sometimes useful. HTH, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
må 2006-06-19 klockan 00:18 +0300 skrev Tor Lillqvist: >I think it is possible to get the same effect as FD_CLOEXEC, though, by > duplicating the socket using DuplicateHandle() to be non-inheritable, > closing the original, and using the duplicated socket instead. Will have > to try. Indeed, works like a charm. I am a bit embarrassed now, though, that I so lightly had just ifdeffified the code in ORBit2 that does FD_CLOEXEC on the sockets, without really thinking what consequences there might be on Windows when sockets get inherited. Oh well. Luckily there doesn't seem to be that many uses of FD_CLOEXEC in the GNOME libs that I have ported, or Evo. Most of them are in code for functionality that is ifdeffed out for Windows completely anyway. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
lö 2006-06-17 klockan 02:23 +0300 skrev Tor Lillqvist: > I should still of course also investigate why the other (unknown) > mechanism which causes unregistration to happen anyway on Unix doesn't > work on Windows... I think I have a good guess now: The problem is that all sockets by default are inherited by child processes in Windows. (Like file descriptors in Unix.) Thus even if the Evolution process, which created the socket and was listen()ing on it dies, the socket still exists in LISTENING state as it has been inherited by the processes that Evolution has started (bonobo-application-server), even though said processes are blissfully unaware of it... This doesn't happen on Unix because ORBit2 sets FD_CLOEXEC on the sockets it creates. FD_CLOEXEC doesn't exist as such in Windows, so that code is just ifdeffed out, and I haven't really much thought about what consequences this might have... until now. I think it is possible to get the same effect as FD_CLOEXEC, though, by duplicating the socket using DuplicateHandle() to be non-inheritable, closing the original, and using the duplicated socket instead. Will have to try. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
> If my analysis is correct, this means that attempting to do a CORBA
> object unregistration in the GObject finalize method is too late, isn't
> it?
I tested by applying this simple patch to e-shell.c, moving the
bonobo_activation_active_server_unregister() call from impl_finalize()
to notify_no_windows_left_idle_cb():
Index: shell/e-shell.c
===
RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
retrieving revision 1.272
diff -p -u -r1.272 e-shell.c
--- shell/e-shell.c 30 Jan 2006 11:49:53 - 1.272
+++ shell/e-shell.c 16 Jun 2006 23:17:50 -
@@ -360,13 +360,18 @@ static gboolean
notify_no_windows_left_idle_cb (void *data)
{
EShell *shell;
+ EShellPrivate *priv;
shell = E_SHELL (data);
+ priv = shell->priv;
set_interactive (shell, FALSE);
g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
+ if (priv->iid != NULL)
+ bonobo_activation_active_server_unregister (priv->iid,
+
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
bonobo_object_unref (BONOBO_OBJECT (shell));
return FALSE;
@@ -467,10 +472,6 @@ impl_finalize (GObject *object)
shell = E_SHELL (object);
priv = shell->priv;
-
- if (priv->iid != NULL)
- bonobo_activation_active_server_unregister (priv->iid,
-
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
e_free_string_list (priv->crash_type_names);
And lo and behold, it works! Now the ESHell gets unregistered, and when
starting Evolution again it manages to register its EShell and contact
the already running e-d-s etc.
OK to apply this patch to HEAD and stable? ChangeLog entry:
2006-06-17 Tor Lillqvist <[EMAIL PROTECTED]>
* e-shell.c (impl_finalize): Don't call
bonobo_activation_active_server_unregister() here, it's too late,
the EShell Bonobo object has already been deactivated and its
associated CORBA object is NULL.
(notify_no_windows_left_idle_cb): Instead, call
bonobo_activation_active_server_unregister() here, when the EShell
Bonobo object is still fully active.
I should still of course also investigate why the other (unknown)
mechanism which causes unregistration to happen anyway on Unix doesn't
work on Windows...
--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
I am debugging why Evo on Windows doesn't manage to reuse the evolution-data-server process that is left running when you quit Evolution. One possible hint to the cause is that when you quit Evolution on Windows, for some reason it seems that it doesn't manage to unregister the EShell from the bonobo-activation-server. (If one checks with bonobo-browse, it still says that the Shell is Active.) Debugging the code where Evolution tries to unregister turns up some interesting stuff. It's the impl_finalize() in evolution/shell/e-shell.c that calls bonobo_activation_active_server_unregister(). However, at that stage the BonoboObject::corba_objref field of the BonoboObject (EShell) object is already NULL. This is obvious, because if one checks the backtrace from impl_finalize(), what causes it do be called is the call to g_object_unref() in bonobo_object_finalize_internal_T() (libbonobo/bonobo/bonobo-object.c). And that function has a few lines earlier called bonobo_object_corba_deactivate_T(), which sets corba_objref to NULL. Anyway, this means the second parameter to bonobo_activation_active_server_unregister() is NULL, which is then passed on as third parameter to Bonobo_ObjectDirectory_unregister(). This NULL eventually ends up as the object parameter to remove_active_server() in libbonobo/activation-server/object-directory-corba.c in the bonobo-activation-server process, and it obviously doesn't match the registered EShell server, so no removal happens. If my analysis is correct, this means that attempting to do a CORBA object unregistration in the GObject finalize method is too late, isn't it? Apparently, unregistration still works on Unix, though, as if you run bonobo-browse after quitting Evolution on Unix, there indeed is no Shell listed as Active. Maybe the bonobo-activation-server notices that the socket connection hangs up and then automatically unregisters, or something? Hmmm. Oh well, why this other mechanism then doesn't work on Windows needs to be debugged now... --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
