GNOME Bugzilla – Bug 136986
g-s-d fails to connect with at-spi-registryd at startup
Last modified: 2004-12-22 21:47:04 UTC
gnome settings daemon seems to fail to connect with at-spi-registryd on startup, though it does load the appropriate g_modules (gail, atk-bridge). Easy to imagine why this might happen. It wouldn't matter at all, except that it means that any dialogs which g-s-d posts (for instance the StickyKeys warning) will be inaccessible to blind users and difficult to use for GOK users. FOrtunately most blind users will not need stickykeys, but this could still be an annoyance since they won't be notified of the dialog.
Why is this bug logged against control-center instead of at-spi?
I have noticed a core file from at-spi-rregistryd in my home directory. I do not have proof that it is related to this problem but I will investigate. core 'core' of 3165: /usr/lib/at-spi-registryd --oaf-activate-iid=OAFIID:Accessibility_Regi fe3aeaf0 strlen (fefe6cff, ffbfe40c, fe41134c, ffbfd665, 0, 73) + 50 fe415560 vsnprintf (ffbfde1f, 1, fefe6ce8, ffbfe408, 7ffffc00, 6) + 6c fe6df5f8 g_printf_string_upper_bound (fefe6ce8, ffbfe408, fdfc8000, ff3ea9d8, 2f384, ff3ea234) + 10 fe6fe2d0 g_vasprintf (ffbfdee4, fefe6ce8, ffbfe408, ff3bf26c, ff3ea9d8, fe72e000) + 44 fe6ecf28 g_strdup_vprintf (fefe6ce8, ffbfe408, ff042060, 14, 0, 1) + 10 fe6de878 g_logv (fefe6ca4, fe73ec00, 5, ffbfe408, 10, 10) + 2c4 fe6de948 g_log (fefe6ca4, 10, fefe6ce8, 0, ff002068, 1224) + 1c fef953d4 gdk_init (1, 0, 0, 69924, 3c954, feffeca0) + 64 00023b1c spi_registry_init (50848, 50748, 23af8, 50848, 505d0, 0) + 24 fe7cc618 g_type_create_instance (50598, 50848, 50748, 506d0, fe7eeb20, 50708) + adc fe7b1bac g_object_constructor (506d0, 1, 4de60, 0, 0, 0) + 4 ff18a318 bonobo_object_constructor (506d0, ff1d4124, 4db80, fdfc8000, 3eeb4, fe6d1c4c) + 38 fe7b1148 g_object_newv (506d0, ff18a2e0, 4de60, 1, 50748, 4de68) + 328 fe7b0d20 g_object_new (506d0, 0, fe466170, 58c38, ff1caa00, fe7d9800) + 60 00023ce0 spi_registry_new (1, 1400, fe73ecc0, 1670, 1400, 0) + 10 00021778 main (3, ffbfe8e4, ffbfe8f4, 3d400, fdfc0140, fdfc0180) + 58 0001a0d8 _start (0, 0, 0, 0, 0, 0) + 108
This bug was logged against control-center since other apps can successfully connect, so there is something specific to the startup environment of g-s-d which is influencing the problem. Padraig, do you have any new information? I can tell little from the bt above.
The bt could have been the result of a failure to connect to the x server at startup, perhaps due to a bad value of DISPLAY; hard to be sure.
I am coming around to the view that the stack trace above is not relevent to this bug. I am contining to investigate what happens when gnome-settings-daemon starts when attepting to connect to the registry.
When atk_bridge_init() is executed for gnome-settings-daemon bonobo_activation_iid_get() returns TRUE so spi_atk_bridge__do_registration() is not called. Is this correct?
looks rather like a dup of 144086.
About Comment #6: If bonobo_activation_iid_get() returns TRUE, then spi_atk_bridge_do_registration should be deferred until the first toplevel window is created (which should result in a call to spi_atk_bridge_toplevel_added, via the children_changed:added signal handler on atk_get_root()).
The application is registered when it should be. However the first call to Accessibility_Registry_notifyEvent fails; it is for the window:create event. I have a truss file of all the processes started at login. One of the worrying things I see is that quite a large number of at-spi-registryd processes are started. It looks like a new at-spi-registryd process is started when gnome-settings-daemon registers. This at-spi-registryd process exits for reasons which are not clear to me.
I have trolled through the registryd sources and I don't see anyplace after the initial call to main() (before entering the bonobo main loop) where the registry ever explicitly exits or quits, i.e. no calls to exit(), g_error(), *_shutdown*, etc. So perhaps this is an abnormal termination exit (SEGV?) or bonobo is exiting. Padraig, how are you tracing the registry in this case? Perhaps I can use the same techniques on my JDS linux setup.
I am using g_print call and trussing all the processes started on login with -w 1 to see the text that is being output. I then grep on particular pids to get the truss output for the processes I am interested in into separate files. The reason why new at-spi-registryd processes are being started is that the call to Bonobo_ActivationEnvironment_match() in od_get_active_server() returns FALSE for OAFIID:Accessibility_Registry:1.0. Thereason I know this is the causae of the problem is that if I pretend that Bonobo_ActivationEnvironment_match returns TRUE only one at-spi-registryd process starts and the problem in bug #144418 no longer occurs. The reason that the call to Bonobo_ActivationEnvironment_match fails is the the stored Bonobo_ActivationEnvironment is DISPLAY=0:0 and the Bonobo_Activation_environment associated with gnome-settings-daemon is DISPLAY=:0;LANG=C;LC_ALL=C Bill, Do you know how the Bonobo_ActivationEnviroment is set?
THis is almost identical to the problem(s) we had with activation in gdm. Looks as though Bonobo_ActivationEnvironment is set in bonobo_activation_init_activation_env, in bonobo-activation-activate.c. Set appears to use getenv(), so it's not totally clear why g-s-d is passing a different Bonobo_Activation_environment string.
It looks like some processes have environment variable DISPLAY set to :0 and some to :0.0 and that this is the cause of our problem. I am continuting to dig into truss files to figure out why.
It looks like gnome-session is the culprit. It is called with DISPLAY environment variable set to :0 but all child processes are called with DISPLAY environment variable set to :0.0
Padraig: Is this because gnome-session is launched by gdm? Where does gnome-session get its env, does it just inherit it from the shell, yet somehow re-set the env for its children?
I asume gnome-session inherits its environment from its parent. I have found the following code in main.c of gnome-session. I need to check that this is what causes the change of the DISPLAY environment variable. /* Make sure children see the right value for DISPLAY. This is useful if --display was specified on the command line. */ ep = g_strconcat ("DISPLAY=", gdk_get_display (), NULL); putenv (ep);
I have committed a change to at-spi which I believe will sort this problem; rather than doing our activation based on the DISPLAY environment variable, we are creating a new AT_SPI_DISPLAY env variable which is canonicalized, strips the screen number (which in most cases we don't want to treat as significant anyway), and is passed to the cspi and bridge activation environment. See patch for bug #144086.