GNOME Bugzilla – Bug 540537
Orca does not provide access to applications which were launched prior to it in GNOME 2.23
Last modified: 2008-07-26 05:33:50 UTC
Steps to reproduce: 1. Launch gnome-terminal 2. Launch Orca 3. Attempt to access the menus in gnome-panel or in gnome-terminal Expected results: Orca would provide access to those items. Actual results: Orca does not provide access to those items. Notes: This is in Ubuntu Intrepid. Orca has no problem with applications launched after it. For instance, if you launch Orca from an xterm and then start gnome-terminal, Orca works as expected in gnome-terminal. The same behavior can be seen in Accerciser (i.e. the only things that show up in the hierarchy are applications which were launched after Accerciser). After much hair pulling, the change responsible seems to be libbonobo, in particular, revision 3461: http://svn.gnome.org/viewvc/libbonobo/trunk/bonobo-activation/bonobo-activation-base-service.c?r1=3460&r2=3461&pathrev=3461 When I install revision 3460 from trunk Orca works as expected; install revision 3461 (and subsequent builds) and it's broken. Question: Is the above change something valid that exposed a bug on the at-spi side of things, or is this a bonobo bug?
Can you tell me how many copies of bonobo-activation-server you have running for your username? (ps -ef |grep bonobo should say) The change ties bonobo-activation-server to the dbus session. If there's no session to tie to, then it falls back to the old behavior of a well known location in /tmp. It could be that the ATs are getting started before dbus, and so are running outside of the session, then dbus gets started and everything run afterward gets run within the session. If there is more than one bonobo-activation-server process for your username, then that would confirm this theory.
(In reply to comment #1) > Can you tell me how many copies of bonobo-activation-server you have running > for your username? 1 before the change; 2 after: Rev 3460 jd 5402 1 0 09:39 ? 00:00:00 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=12 Trunk jd 5390 1 0 13:28 ? 00:00:00 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=12 jd 5477 1 0 13:28 ? 00:00:00 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=19 Thanks for looking into this Ray!
Hi, Would you mind attaching a complete "ps -ef" output and also the output of for pid in $(/sbin/pidof bonobo-activation-server gnome-panel gnome-terminal); do echo "server $pid has environment:" strings /proc/$pid/environ done
Created attachment 113799 [details] requested output
> root 4995 1 /usr/sbin/gdm > root 4997 4995 /usr/sbin/gdm So we have the gdm slave started here at pid 4997 (not sure why it's called gdm instead of gdm-binary, but that's probably some unrelated change) > root 5003 4997 /usr/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7 It starts X > jd 5210 4997 x-session-manager > jd 5294 5210 /usr/bin/ssh-agent /usr/bin/seahorse-agent --execute x-session-manager > jd 5297 1 /usr/lib/libgconf2-4/gconfd-2 13 > jd 5303 5210 /usr/bin/seahorse-agent --execute x-session-manager And the session. Note, it probably ran /usr/bin/ssh-agent /usr/bin/seahorse-agent --execute x-session-manager first, and then the agents forked off and handed off the original pid to x-session-manager At this step dbus should already be running. Since the session bus scopes the session, it needs to be run before the session starts. There might be something funky with distro scripts here, since it's not running. > jd 5305 5210 /usr/lib/at-spi/at-spi-registryd The session manager (or maybe seahorse when it owned pid 5210) is starting at-spi-registryd > jd 5312 1 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=12 Which needs bonobo-activation-server and so it starts it. > jd 5323 1 dbus-launch --autolaunch f047151b9917527e477d121c48646540 --binary-syntax --close-stderr > jd 5324 1 //bin/dbus-daemon --fork --print-pid 15 --print-address 17 --session bonobo-activation-server tries to get on the session bus, but it doesn't exist, so an isolated bus gets autolaunched. > jd 5326 1 /usr/bin/gnome-keyring-daemon The session manager starts keyring daemon > jd 5329 1 dbus-daemon --fork --print-address 29 --print-pid 31 --session Something is starting dbus again. Maybe the session manager notices that DBUS_SESSION_BUS_ADDRESS isn't set (since the bus was autolaunched instead of started properly) and then tries to start a bus as a failsafe measure. That's just a guess. If that's what it's doing, then it should probably check for the X selection that the autolaunched buses takes ownership of in addition to the DBUS_SESSION_BUS_ADDRESS environment variables. Or maybe it should just not ever start a bus. The bus will get started too late in the session lifecycle anyway. > jd 5331 1 gnome-settings-daemon > jd 5343 5331 /usr/bin/pulseaudio --log-target=syslog > jd 5347 5343 /usr/lib/pulseaudio/pulse/gconf-helper > jd 5351 1 /usr/lib/gvfs/gvfsd > jd 5357 1 /usr/lib/gvfs//gvfs-fuse-daemon /home/jd/.gvfs > jd 5371 5210 /bin/sh /usr/bin/compiz --sm-client-id default0 > jd 5373 5210 gnome-panel --sm-client-id default1 > jd 5374 5210 nautilus --no-default-window --sm-client-id default2 More of the session starts up. > jd 5391 1 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=19 gnome-panel needs bonobo-activation-server. Since it's using a different session bus than the other bonobo-activation-server it can't find it, so it starts its own. > [ ... snip more session start up... ] > jd 5636 1 gnome-terminal > jd 5653 5636 gnome-pty-helper Terminal is started some how (from panel? nautilus? automatically from session?). > jd 5654 5636 bash > jd 5706 5654 /bin/bash /usr/bin/orca > jd 5708 5706 /bin/bash /usr/bin/orca > jd 5731 5708 /usr/bin/python -c import orca.orca; orca.orca.main() > jd 5784 1 /usr/lib/at-spi/at-spi-registryd --oaf-activate-iid=OAFIID:Accessibility_Registry:1.0 --oaf-ior-fd=38 > jd 5803 1 /usr/bin/swift-synthesis-driver --oaf-activate-iid=OAFIID:GNOME_Speech_SynthesisDriver_Swift:proto0.3 --oaf-ior-fd=39 And orca is started. This orca starts another at-spi-registryd since the other one is registered with othe other bonobo-activation-server which isn't available since its on a different session bus. It seems like the root problem here is Ubuntu Intrepid isn't starting a session bus before starting the session. Sebastien, do you know how Ubuntu's Xsession script starts dbus? Is it known broken for Intrepid right now?
there is no xsession script to start dbus on a standard ubuntu installation since gnome-session is already doing that, do you have anything starting dbus installed in /etc/X11/Xsession.d on your box?
Oh that's the problem, dbus should be started before the session not after, since it defines the scope of the session. Sebastien, what do you do if things in /etc/X11/Xsession.d need access to the bus?
Also, would you be opposed to adding something like if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then eval `dbus-launch --sh-syntax --exit-with-session` fi to -start-messages-bush.sh in /etc/X11/Xsession.d ?
Adding Lucas
you can read http://bugzilla.gnome.org/show_bug.cgi?id=360475 about why we changed dbus to by started by gnome-session, having it start before gnome-session means the environment is not correct set and leads to other issues
Hi Joanmarie, Are you using gnome-session 2.22?
> Are you using gnome-session 2.22? Seems that I am. 2.22.1.1 in particular.
*** Bug 542451 has been marked as a duplicate of this bug. ***
*** Bug 542455 has been marked as a duplicate of this bug. ***
I now have gnome-session 2.23.5 and am no longer seeing this issue. (Yea!) I'm not sure that we're "blocked" -- or if there's anything we need to do about this bug. Will?
(In reply to comment #15) > I now have gnome-session 2.23.5 and am no longer seeing this issue. (Yea!) > > I'm not sure that we're "blocked" -- or if there's anything we need to do about > this bug. Will? > I'm thinking if it's fixed, it's fixed, so close it. :-)
The issue is less severe with 2.23 because of the order things are started. 2.23 does regress 360475 though, but we can address that issue there.