Created attachment 112472 [details]
full valgrind log

Looks like a problem in xklavier or, more likely, the X server to me. Sergey?

It looks like internal xlib issue. Does it crash without valgrind? Would you set XKL_DEBUG=200 and see what exactly is passed to XkbWriteToServer?

Where does the output end up? I don't see anything on the console here.

Created attachment 112714 [details]
valgrind log from running only g-s-d under valgrind

This is what the log looks like if I first start the session and then kill g-s-d and rerun it under valgrind.

This log does not actually show any output from libxklavier. Did you set XKL_DEBUG envvar?

I tried setting that but it didn't give any more output. Neither on the console when running g-s-d again nor in the log in ~/.xsession-errors

Are you sure your libxklavier build is not broken? export XKL_DEBUG=150 (and more) makes libxklavier very verbose on stdout. Unless it is intercepted by someone of course...

Hmm. ldd says gnome-settings-daemon isn't linked to libxklavier at all in my build. How can that be? Is something else pulling in libxklavier?

Would you check the g-s-d plugins? In particular - keyboard plugin.

The backtrace ends up in libX11 it seems.

==4861== Invalid read of size 1
==4861==    at 0x517C08C: SendSetMap (XKBSetMap.c:331)
==4861==    by 0x517CBD4: XkbSetMap (XKBSetMap.c:532)
==4861==    by 0x67133F1: XkbWriteToServer (srvmisc.c:52)
==4861==    by 0x66FABB6: (within /usr/lib/libxklavier.so.12.1.0)
==4861==    by 0x66FB150: xkl_xkb_activate_config_rec (in /usr/lib/libxklavier.so.12.1.0)
==4861==    by 0x66F6EC1: xkl_config_rec_activate (in /usr/lib/libxklavier.so.12.1.0)
==4861==    by 0x66C65C6: gkbd_keyboard_config_activate (gkbd-keyboard-config.c:666)
==4861==    by 0x66BE2C2: apply_xkb_settings (gsd-keyboard-xkb.c:187)
==4861==    by 0x66BE7A8: gsd_keyboard_xkb_init (gsd-keyboard-xkb.c:365)
==4861==    by 0x66BD9E8: gsd_keyboard_manager_start (gsd-keyboard-manager.c:402)
==4861==    by 0x66BCF5C: impl_activate (gsd-keyboard-plugin.c:78)
==4861==    by 0x804C2D6: gnome_settings_plugin_activate (gnome-settings-plugin.c:52)
==4861==    by 0x804D36B: _activate_plugin (gnome-settings-plugin-info.c:506)
==4861==    by 0x804D47A: gnome_settings_plugin_info_activate (gnome-settings-plugin-info.c:529)
==4861==    by 0x804B41A: maybe_activate_plugin (gnome-settings-manager.c:93)
==4861==    by 0x4ED27AE: g_slist_foreach (gslist.c:743)
==4861==    by 0x804B94A: _load_all (gnome-settings-manager.c:271)
==4861==    by 0x804BB31: gnome_settings_manager_start (gnome-settings-manager.c:348)
==4861==    by 0x804B07A: main (main.c:312)
==4861==  Address 0x6739fe0 is 0 bytes after a block of size 256 alloc'd
==4861==    at 0x4027192: calloc (vg_replace_malloc.c:397)
==4861==    by 0x51873CD: XkbAllocServerMap (XKBMAlloc.c:170)
==4861==    by 0x672535B: ReadXkmSymbols (xkmread.c:647)
==4861==    by 0x6725EA2: XkmReadFile (xkmread.c:1293)
==4861==    by 0x66FA8F0: (within /usr/lib/libxklavier.so.12.1.0)

Also I see this further down in the log:

==4861== Warning: invalid file descriptor -1 in syscall write()
==4861==    at 0x4E1F0BB: (within /lib/libpthread-2.8.90.so)
==4861==    by 0x66AAD6B: stop_gnome_sound (gsd-sound-manager.c:199)
==4861==    by 0x66AB1E7: gsd_sound_manager_stop (gsd-sound-manager.c:406)
==4861==    by 0x66AA800: impl_deactivate (gsd-sound-plugin.c:89)
==4861==    by 0x804C35A: gnome_settings_plugin_deactivate (gnome-settings-plugin.c:60)
==4861==    by 0x804CDAF: _deactivate_plugin (gnome-settings-plugin-info.c:354)
==4861==    by 0x804CE81: gnome_settings_plugin_info_deactivate (gnome-settings-plugin-info.c:367)
==4861==    by 0x804B970: _unload_plugin (gnome-settings-manager.c:279)
==4861==    by 0x4ED27AE: g_slist_foreach (gslist.c:743)
==4861==    by 0x804B9A5: _unload_all (gnome-settings-manager.c:287)
==4861==    by 0x804BBA6: gnome_settings_manager_stop (gnome-settings-manager.c:381)
==4861==    by 0x804ACC1: on_session_over (main.c:172)
==4861==    by 0x4E588FC: g_cclosure_marshal_VOID__VOID (gmarshal.c:77)
==4861==    by 0x4B923DE: marshal_dbus_message_to_g_marshaller (dbus-gproxy.c:1665)
==4861==    by 0x4E3FAE2: g_closure_invoke (gclosure.c:769)
==4861==    by 0x4E57DA2: signal_emit_unlocked_R (gsignal.c:2976)
==4861==    by 0x4E56EEB: g_signal_emit_valist (gsignal.c:2708)
==4861==    by 0x4E57215: g_signal_emit (gsignal.c:2766)
==4861==    by 0x4B9361E: dbus_g_proxy_manager_filter (dbus-gproxy.c:1718)
==4861==    by 0x4BAEF24: dbus_connection_dispatch (dbus-connection.c:4393)
==4861==    by 0x4B8A08C: message_queue_dispatch (dbus-gmain.c:101)
==4861==    by 0x4EAFB93: g_main_dispatch (gmain.c:2066)
==4861==    by 0x4EB1063: g_main_context_dispatch (gmain.c:2618)
==4861==    by 0x4EB15B8: g_main_context_iterate (gmain.c:2699)
==4861==    by 0x4EB1D94: g_main_loop_run (gmain.c:2922)
==4861==    by 0x4186AF4: gtk_main (gtkmain.c:1172)
==4861==    by 0x804B0BB: main (main.c:321)

I would say it is rather libx11's issue than libxklavier's. But without debug trace I cannot be 100% sure (I mean output of libxklavier with XKL_DEBUG)

*** Bug 546766 has been marked as a duplicate of this bug. ***

Any chance to get debug output for that bug?

Created attachment 116179 [details]
libxklavier log

Here you go. I can reproduce this when switching screen resolution in the display capplet. Strangely enough only when going from 1280x1024 to 1280x960 it seems.

*** Bug 546760 has been marked as a duplicate of this bug. ***

*** Bug 546767 has been marked as a duplicate of this bug. ***

I suspect the valgrind trace and the crash (which I assume is happening when setting up the screen with xrandr) are actually unrelated, though.

I tried various resolution settings - it does not break for me :(

Jens, do you see the same backtrace as Kjartan? Why does the plugin reactivated on the resolution change?

Because for some reason xklavier seems to intercept XErrors.

I haven't tried valgrind, yet.

Soeren suspects some connection to the X driver being used. I'm currently using the "nvidia" legacy driver here.

This is the proper trace when using --sync.

+ Trace 204868

I'm using the intel driver just FYI.

I think this really needs to be fixed before 2.24. We've already got a couple of duplicates, with different graphics drivers, so this is going to bite us if we release like this. So we either need to catch the X error, or better yet, not cause it in the first place (which probably means, in gnome-desktop).

Soeren, you wanted to look at this. Any news?

Not yet, but I do want to take a look at it.

I can reproduce this on a Matrox card. What's going on is that turning off the CRTC fails, which in turns leads to the screen size being set such that the crtc doesn't fit into which leads to the badmatch.

I'll try and come up with a patch over the weekend.

Soeren, any update ?

Fixed in gnome-desktop

Tue Sep 16 11:23:05 2008  Søren Sandmann  <sandmann@redhat.com>

	* gnome-rr.c (gnome_rr_crtc_set_config): Propagate errors from
	XRRSetCrtcConfig() 

	* gnome-rr-config.c (crtc_assignment_apply): Don't try and set the
	screen size if turning off any of the CRTC's failed.

	Fix bug #537592

After applying those changes I can now no longer switch resolutions using the capplet at all. Selecting any resolution and pressing "Apply" results in some sort of reresh, then the combobox goes back to the original setting and nothing changes.

Created attachment 118845 [details] [review]
fix success check

(also note that we were code frozen when the first patch was applied :/)

Jens' patch seems to be okay to me.

Sorry, I didn't realize there was a code freeze in effect. 

The patch looks good to me too.

Note though, that on some hardware, being unable to switch resolution at all is unfortunately the expected result (even with Jens' patch). See bug 552509. I hope to fix this for 2.24.1.

Release-Team Approval 2 of 2. Please commit and include for 2.24.0.
(First approval was by Vincent Untz.)

andre

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.