GNOME Bugzilla – Bug 144920
gnopernicus/srcore exits when launched via GDM a11y gesture
Last modified: 2004-12-22 21:47:04 UTC
Using GNOME built with gnopernicus source tarball 0.9.5 on 17th June 2004: -Set up a gestures to launch srcore in /etc/X11/gdm/modules/AccessKeyMouseEvents Such as: <Control>s 1 1000 10000 srcore --login --enable-speech # gnopernicus magnifier <Control>m 1 1000 10000 srcore --login --enable-magnifier # both <Control>g 1 1000 10000 srcore --login - Restart the GDM2 login (gdmlogin) - Log out - At the GDM2 login, hold <Control>m for over a second and release The gnopernicus magnifier should launch See that no mouse tracking occurs in the magnifier zoomer. srcore has exited, and this renders magnification (or speech/braille) unuseable for login through the GDM greeter.
Starting gnopernicus/srcore with speech support at login time can not work because of gnome-speech. Bill please try to launch srcore with a line like: srcore --login --enable-magnifier --disable-speech
Hi Patrick, On SuSe 9 using : srcore --login --enable-magnifier --disable-speech everything works. However on your system please try the folowing things: 1. register a gesture listener for gnome-terminal or xterm <Control>t 1 0 0 /usr/bin/gnome-terminal or <Control>x 1 0 0 /usr/bin/xterm 2. go and edit /etc/passwd - there you will find a line similar to this one: gdm:x:50:50:Gnome Display Manager Daemon:/var/lib/gdm:/sbin/nologin -please use instead of "/sbin/nologin" this "/bin/bash". Ok , now you can use xterm or gnome-terminal at gdm time. 3.restart gdm (or the system) , start xterm or gnome-terminal using the gesture listener and in the terminal type: srcore --login --enable-magnifier --disable-speech You should see everything working ok now. Since being launched from a terminal, everything works ok and when launched via gesture listener srcore exits, I think this is a gdm bug. Unfortunately I don't see a way to get a stack trace.
I did the folowing experiment: I created a script in /usr/bin in that script I wrote : echo root_password | su -c "srcore --login --enable-magnifier --disable-speech" I called this script from a GDM Gesture <Control>s for example. By running srcore as root, everything worked OK, so I think that this is a GDM bug.
Starting srcore and debugging it remotly showed us that the reason srcore exited was the fail of the at-spi function : SPI_registerGlobalEventListener Stepping trough code shows that cspi_init function is called from srcore , so a connection to at-spi registryd is attempted by srcore. Note that if launched from a terminal or if run as root by using a script everything works OK. Since this seems to be a at-spi bug, I'm reasigning it to at-spi.
There isn't much evidence about this being an at-spi bug one way or another.
Note that this bug doesn't occur with my community HEAD build.
We did some investigations. We run step by step some functions from at-spi. First was SPI_init. This is in fact a call for cspi_init. So, we run this one step by step. We also checked the returned value from bonobo_activate. _All_ calls succeded (no branch for error was reached). After some steps (all run with success) srl_init function was called. Function SPI_createAccessibleEventListener succeded. Then, SPI_registerGlobalEventLister was called. This function failed.We tried to see why. This function is a call to Accessibility_Registry_registerGlobalEventListener. It has some parameters, most of them are function calls. cspi_registry tries to ping the registry daemon (we guess that), and in case of failure calls cspi_init. After returning from Accessibility_Registry_registerGlobalEventListener, cspi_exception is called. In this case, there is a CORBA error (stored in ev variable). ev._major has value 2 (CORBA_SYSTEM_EXCEPTION), and call to bonobo_exception_get_text (wrote by us) returned "Unknown CORBA exception id: 'IDL:omg.org/CORBA/COMM_FAILURE:1.0'" So, we think that there is a problem with the comunication beetwen srcore and at-spi registryd because both functions that try to communicate from srcore to registryd (cspi_ping and Accessibility_Registry_registerGlobalEventListener) failed. IMPORTANT: No break put in registryd process was reached. This also sustains our oppinion above. IMPORTANT2: We also put a break point on cspi_exception when srcore was launched (with _same_ arguments) after login (as regular user) and ther was no exception .
Hi Bill, Here is the line in gnopernicus where the function that fails (SPI_registerGlobalEventListener) is called: gnopernicus/srlow/libsrlow/libsrlow.c line no. 1734 And the line where the srl_error (which is in fact a g_error macro ) macro is called when checking the return of SPI_registerGlobalEventListener gnopernicus/srlow/libsrlow/libsrlow.c line no. 1737 Hope this helps.
We did another test, Start at-poke from a gesture listener. At poke starts but the GDM window doesn't appear in at-poke, so you can't do anything. Also if started from a terminal, at-poke works OK, you can poke the GDM login window.
THanks Dragan. The info is helpful.
This bug does not strike with gdm2 from HEAD, without sun-specific patches.
I agree, also on SUSE 9.0 with gdm2 from HEAD, everything works OK.