GNOME Bugzilla – Bug 77203
gnome2-settings-daemon cores on keyboard accesibility settings.
Last modified: 2009-08-15 18:40:50 UTC
Solaris nightly CVS tip build from: cvs -q co -D 'Mon Apr 1 04:26:00 BST 2002' gnome-control-center Starting gnome-session causes gnome2-settings-daemon to core with the following traceback: program terminated by signal SEGV (no mapping at the fault address) Current function is set_server_from_gconf 104 desc->ctrls->ax_options = XkbAX_LatchToLockMask; (.../forte/6u2_FCS/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where current thread: t@1 =>[1] set_server_from_gconf(ignored = (nil)), line 104 in "gnome-settings-accessibility-keyboard.c" [2] gnome_settings_accessibility_keyboard_load(client = 0x96aa8), line 301 in "gnome-settings-accessibility-keyboard.c" [3] gnome_settings_daemon_new(), line 270 in "gnome-settings-daemon.c" [4] main(argc = 2, argv = 0xffbffbe4), line 31 in "factory.c" (.../forte/6u2_FCS/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) (.../forte/6u2_FCS/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) _LatchToLockMask < dbx: "XkbAX_LatchToLockMask" is not defined in the scope `gnome2-settings-daemon`gnome-settings-accessibility-keyboard.c`set_server_from_gconf` dbx: see `help scope' for details (.../forte/6u2_FCS/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) print XkbAX_LatchTo > dbx: "XkbAX_LatchToLockMask" is not defined in the scope `gnome2-settings-daemon`gnome-settings-accessibility-keyboard.c`set_server_from_gconf` (.../forte/6u2_FCS/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) >ctrls->ax_options < dbx: cannot access address 0x22
desc at the time of the crash: print *desc *desc = { dpy = 0x70410 flags = 0 device_spec = 256U min_key_code = '\0' max_key_code = '\0' ctrls = (nil) server = (nil) map = 0xb1018 indicators = (nil) names = (nil) compat = (nil) geom = (nil) }
Created attachment 7499 [details] [review] Be anal retentive
This does not solve the underlying problem of why your X server is not populating that field as expected. The code in question was taken directly from the X11R6 source tree, so much for that idea. This patch just adds more protection around the X calls to keepus from crashing. The real question that should be answered before this bug is closed is Why did your X server not handle that call ? I'll guess that the XKB extension is not installed or disabled ? If so we should handle that more gracefully than spewing warnings in the settings daemon.
Jody, Good point looking at the man page for XkbGetMap, I'm not sure how anything is populated when the 'which' (2nd argument) is 0: To allocate an XkbDescRec structure and populate it with the server's keyboard client map and server map, use XkbGetMap. XkbGetMap is similar to XkbGetKeyboard, but is used only for obtaining the address of an XkbDescRec structure that is populated with keyboard mapping components. It allows finer control over which substructures of the keyboard mapping components are to be populated. XkbGetKeyboard always returns fully populated components, while XkbGetMap can be instructed to return a partially populated component. The which mask is a bitwise inclusive those portions of the keyboard server map and the keyboard client maps that are specified in which are allocated and populated.
This no longer cores as of April 4 CVS tip. I'm not sure if the accessibility settings work as they should though.
Ignore/Remove that last attachment. The crash still occurs on the latest build
*** Bug 77725 has been marked as a duplicate of this bug. ***
*** Bug 77775 has been marked as a duplicate of this bug. ***
From one of the duplicates: --- this prevents changes being applied through the following capplets: - Font (bugid: 73566) - Keyboard (bugid: 73571) - Mouse (bugid: 73572) --- Jody, Jacob: if you guys could look into this, I'd appreciate it- it looks like a pretty bad Solaris problem that we should fix ASAP.
I've got a patch that I'm testing. The comment that XkbGetMap may act strangely is possible, the docs are unclear. However, almost every usage that I can find passes which=0. I've tacked on a which == everything and attempted to init ctrls to NULL just to be sure. There is probably a leak in here too, but the docs and the common practice are at odds again. As a result, I'll play it safe and just leak a touch, rather than risk screwed the heap.
Updating all cc bugs that have the GNOME2 keyword set to the GNOME2.0 milestone, to help jrb triage/prioritize cc bugs. Filter on 'luis doing GNOME2 work' to ignore this spam.
Ok, the updated patch is in cvs and sun-patches. If this doesn't fix it I don't know what will. I can't get much more anal than this.
tested this against a nightly from 17th april and the GSD runs fine. closing as verified fixed.
closing