GNOME Bugzilla – Bug 558055
Magnification autostart fails on login
Last modified: 2011-11-24 09:40:13 UTC
Hello, The Mag does not autostart correctly if the user logged in to the X session. The Mag starts but it is no Cursor visible and the Focus is frozen. I tested it with 4 different pc´s With and Without Composide. The effect is every time the same. If i Start orca again (with my invisible cursor :) ) and the Orca windows starts. The mag works correctly again. Greetings Chris
Thanks for taking the time to report this bug. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a description of how to reproduce this bug. You'll also need to add a stack trace; please see http://live.gnome.org/GettingTraces for more information about how to do so. Thanks in advance!
I can confirm this problem on Ubuntu Intrepid. What I'm seeing is that Orca ends up not being able to talk to the magnifier (e.g., a COMM_FAILURE occurs), which seems to imply that there is something bad going on between Orca and the magnifier. It might be a Bonobo failure or perhaps something odd going on in gnome-mag.
"http://bugzilla.gnome.org/bug-HOWTO.html and add a description of how to reproduce this bug." ok :). I´ll try to descripe it better. 1. Open the Orca Settings with Default settings. 2. Only activate the Checksbox "Activate Magnification". 3. Apply the Settings 4. Restart the X session or computer. I try to bring an trace if i´m back on my own pc :). "I can confirm this problem on Ubuntu Intrepid." I use Intrepid too. :) Greetings Chris
I did some more testing with this on Ubuntu Intrepid updated as of yesterday. What appears to be happening is that the whole desktop and X Server are crashing now. If I delay the startup of Orca by inserting a "sleep 30" near the top of /usr/bin/orca, the crash doesn't happen and the magnifier starts fine. So, there is at least a workaround for now.
I tried to reproduce the problem on OpenSolaris 2008.11 b101 rc1b. Works fine. No need to modify /usr/bin/orca or anything. I'm guessing this is an X Server bug, but I need to remember how to get a core file.
If I got rid of the NVIDIA driver on my Ubuntu box, I didn't notice the crash. I'm going to CC Luke from Ubuntu on this to see if he has ideas for how to debug X server crashes on Ubuntu.
Created attachment 134288 [details] debug.out (In reply to comment #5) > I tried to reproduce the problem on OpenSolaris 2008.11 b101 rc1b. Works fine. > No need to modify /usr/bin/orca or anything. I'm guessing this is an X Server > bug, but I need to remember how to get a core file. > I'm seeing it -- or at least a very bad issue -- when I try to have Orca autostart with magnification enabled: I log in, Orca launches, magnification starts, several seconds pass, and then I'm back at the login screen. I don't have any tracebacks. Things just die around the time NWAM connects and a notification is displayed. I still need to see if that's a coincidence or not. (I'll look at that next.) Whether it is or not, the sleep trick makes the problem go away.
Created attachment 134290 [details] debug.out with NWAM disabled Disabling NWAM doesn't stop the problem. But having done so, I got a: "TIMEOUT: something has hung. Aborting." Will, are you seeing this problem?
(In reply to comment #6) > If I got rid of the NVIDIA driver on my Ubuntu box, I didn't notice the crash. I forgot to mention, the box on which I'm having these issues has an nvidia card. I just did a clean install of OpenSolaris build 111a on my Toshiba laptop (intel) and am not experiencing any crashes. Looking at the former's /var/adm/messages, I see: May 8 18:01:56 pokey gdm-binary[7843]: [ID 702911 daemon.warning] WARNING: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 That time coincides with the failure I reported in comment #7.
(In reply to comment #8) > Will, are you seeing this problem? Haven't had a chance to try yet. But, note to self: "self, try a few different things with System->Preferences->Sessions->Startup_Programs: 1) use it instead of the built-in mechanism to launch Orca and see what happens 2) use it to launch 'magnifier -z 4 -m -f' and see what happens 3) muck with the built-in mechanism to have it launch 'magnifier -z 4 -m -f' instead of Orca and see what happens. More note to self, by 'built-in' mechanism, I mean System->Preferences->Assistive_Technologies->Preferred_Applications->Accessibility->Visual"
(In reply to comment #10) Heh - I tried it all with no hangs. Then I tried the original problem (launching Orca with the magnifier enabled on login) and saw no hang. So, I guess I'm "lucky" that I have a machine that doesn't hang. :-( I'll need to revert to my other machine for more testing.
I can only reproduce a problem if Orca is involved and set to launch upon login. * System->Preferences->Sessions->Startup Programs to launch magnifier at 4x magnification with split screen or full screen: No problem/works as expected. * System->Preferences->Assistive Technologies->Preferred Applications->Visual Choosing Custom to launch magnification with split screen or full screen: No problem/works as expected If I start magnification through Orca and set Orca to launch at start, Orca eventually kills itself but fails to kill magnifier. If I then kill magnifier, my desktop becomes usable again. (Related: Hooray for virtual console support in OpenSolaris builds >= 122) Still investigating....
Silly question: Why does putting a 'sleep 30' near the top of /usr/bin/orca cause a 30-second delay in Orca starting up (as evidenced by the debug.out timestamp) and speaking, but no delay in magnification starting?
Sorry to be spammy. The other thing I just discovered is that if I prevent Orca from killing itself when it detects a timeout, after a bit of a pause it's all good (Orca speaks, magnifier magnifies, etc.) I'll take a look at alanc's observation in d.o.o#10505, but if the above suggests something else, I wouldn't mind a hint as to what that something else might be. :-)
Okay, never mind what I asked in Comment #13. It really was silly: I could've sworn that I'd removed magnifier from my startup programs.... One more observation for tonight because I'm clearly tired: * If NWAM is enabled and the notification bubble appears while Orca and mag are starting up, Orca will die and magnifier will not be terminated. * If NWAM is disabled and I perform an action that Orca should present (e.g. Alt+F1) while Orca and mag are still starting up, Orca will die and magnifier will not be terminated. * If NWAM is disabled and I sit patiently until Orca and magnifier have started up, there seems to be a healthy chance that Orca will not die and magnifier will work as expected. <shrugs>
Created attachment 142651 [details] dtrace data I've attached two samples of dtrace data. In both cases: * Recording started at login * Orca with magnification started at login via AT properties * The act of probing Orca and magnifier via dtrace was sufficient to give the NWAM applet's notification bubble time to appear and disappear before Orca could get as far as starting magnification. As a result, using this dtrace script, I could not get Orca to hang all by itself. Therefore: The file in which there was no hang contains output from my letting Orca start up and not doing anything until it was completely up (speech, magnification, and braille monitor). In contrast, the file in which there was a hang, I waited until the NWAM applet notification had disappeared. Then I pressed Alt+F1 to get into the Applications menu and arrowed up and down in that menu while waiting for Orca to fully load. Under those circumstances, the bug is reproducible (Orca attempts to come up, magnification loads, Orca times out and kills itself leaving magnification running). While I have not yet been able to spot the magical difference programmatically, let alone stop this behavior properly, I have also not yet been able to find a contradiction to my gut feeling and subjective observations that the failure occurs when there are events to be processed (notification bubbles, menu navigation, etc.) when Orca is not quite at the point where it is ready to do so.
(3.0 Planning Spam-o-rama. Sorry!)
Orca has been slowly but surely getting out of the magnification business. This has been possible thanks to the work done by the developers of screen magnifiers in GNOME and other platforms. Because Orca is now "just" a screen reader, this bug is obsolete.