Bug 466206

Which version of gnome-settings-daemon? And did you update to the latest version?

gnome-settings-daemon-2.24.0-3.fc10.i386

Am fully updated right now.

Could you try launching /usr/libexec/gnome-settings-daemon by hand and gather a backtrace of the crash?
http://fedoraproject.org/wiki/StackTraces

Bastien, I'll try. When I launched the daemon manually, it seemed to work correctly. I've changed the kernel core pattern to /tmp and will try to reproduce. Since the daemon is launched by the /etc/xdg/autostart/ file, do you know if it will create a core dump by itself ?

Well, here's the culprit:

The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 1344 error_code 8 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[1223552760,000,xklavier.c:xkl_engine_start_listen/] 	The backend does not require manual layout management - but it is provided by the application


Since this appears X related, and I am using the nvidia driver (don't really have a choice), I tried reproducing the bug with the "nv" driver, but without success. I can only guess this is an Nvidia-related problem, so unless you think there's still some value in pursuing this, I'm going to close this bug as WONTFIX. Let me know.

Now I have to figure out which g-s-d plugin makes nvidia unhappy... sigh :-(

Most likely not related to the driver directly, but to the X configuration you'd be using for it.

Passing on to libxklavier where the X error occurs.

libxklavier is just the last thing to set up an X error handler.  It's probably unrelated to the problem.

The two plugins that have seen the most churn lately are the background plugin and the xrandr plugin.

Denis can you open up gconf-editor and navigate to

/apps/gnome_settings_daemon/plugins/background

and unchecking active, then try to reproduce.  Once you've tested that one, reactivate it, and then navigate to

/apps/gnome_settings_daemon/plugins/xrandr

uncheck active and try to reproduce.

If you could do those two things and report whether disabling one of them fixes the problem, that'd be great.

It seems to be 'background', at least I'm about 90% sure.

I'm having this problem as well. From what I've seen, it seems to happen on the first login after boot. If I login and have it fail, then 'killall -u tjb' (which logs me out and puts me back to gdm) and login again, it usually works fine..

Can you run gnome-settings-daemon manually with

/usr/libexec/gnome-settings-daemon --no-daemon --sync

under gdb, and break in gdk_x_error

and produce a backtrace, please

FWIW, I'm having the same problem on a laptop with intel graphics so I don't think it's related strictly to nvidia. I just went through a series of reboots since installing the gnome-settings-daemon-2.24.0-7.fc10.x86_64 update this morning and had it work fine 4 reboots in a row. Right when I was ready to say I think it's fixed, it happened again.

I tried running what you wanted there but am not sure I'm doing it right. When I ran it, it never got to gdk_x_error and so it never broke. Here's some of what it says:

(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error) pending.
(gdb) run --no-daemon --sync
Starting program: /usr/libexec/gnome-settings-daemon --no-daemon --sync
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff6d737a0 (LWP 4266)]

** (gnome-settings-daemon:4266): WARNING **: You can only run one xsettings manager at a time; exiting

** (gnome-settings-daemon:4266): WARNING **: Unable to start xsettings manager: Could not initialize xsettings manager.
Detaching after fork from child process 4282.
[New Thread 0x7ffff1684950 (LWP 4283)]
Detaching after fork from child process 4284.
Detaching after fork from child process 4285.
Shutdown failed or nothing to shut down.

Probably not much help.

Created attachment 320235 [details]
g-s-d trace catching gdk_x_error

That was a tough one but I nailed the trace. I had never been able to reproduce the bug when running gsd manually, so I had to change the Session entry to make it run a script that launches an "xterm -e gdb -x cmds" with cmds being "set breakpoint pending on; break gdk_x_error; run --no-daemon --sync --debug". It caught the X error after a few tries. Attached. It is indeed coming from the background plugin.

Let me know if you need some RPMs recompiled with -g3 -O0

This may be a race between nautilus and g-s-d

If they they both call gnome_bg_create_pixmap () and then race to gnome_bg_set_pixmap_as_root_with_crossfade then g-s-d's pixmap could get destroyed by nautilus.

Note, g-s-d has this code:

gnome_bg_load_from_preferences (manager->priv->bg,
                                manager->priv->client);

/* If this is set, nautilus will draw the background and is
 * almost definitely in our session.  however, it may not be
 * running yet (so is_nautilus_running() will fail).  so, on
 * startup, just don't do anything if this key is set so we
 * don't waste time setting the background only to have
 * nautilus overwrite it.
 */
nautilus_show_desktop = gconf_client_get_bool (manager->priv->client,
                                               "/apps/nautilus/preferences/show_desktop",
                                               NULL);

if (nautilus_show_desktop) {
        /* even when nautilus is supposedly handling the
         * background, apply the settings eventually to make
         * people running a nautilus-less session happy */
        manager->priv->timeout_id = g_timeout_add_seconds (8, (GSourceFunc)queue_draw_background, manager);
}

with the assumption being queue_draw_background won't get called for 8 seconds.

That assumption is wrong, because gnome_bg_load_from_preferences queues a "changed" signal which causes queue_draw_background to get called right away.

If we fix that bug, then I think this one will go away, too.

None the less, we should probably grab the server after gnome_bg_create_pixmap() and ungrab the server after copying the end pixmap

Last night I commited code to fix the two above bugs.

I'm going to close this issue. If you still see it with latest rawhide, please reopen.

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

This bug made a stunning come back this morning after yesterday's big batch of updates :-(

I'll try to get a trace again.

So a variant of this bug exists.

gnome-settings-daemon does not crash, it seems to run fine. However there is still some sort of race condition going on, since after I log in all my font sizes are wrong (i.e. they're default sizes, rather than the ones I configured explicitly). As a matter of fact, if I go into the appears menu and change the application font sizes or the font smoothing preference, nothing happens...

yet, gnome-settings-daemon is running (in gdb in my xterm window :-) )... This is after today's updates.

Comparing the gdb output of g-s-d between a good and bad run, the following lines immediately stand out:

** (gnome-settings-daemon:3281): WARNING **: You can only run one xsettings mana
ger at a time; exiting

** (gnome-settings-daemon:3281): WARNING **: Unable to start xsettings manager: 
Could not initialize xsettings manager.

Interesting, what other xsettings manager could you have running ?

The call to XGetSelectionOwner() doesn't return None as expected, but a Window id (39845922). Can you point me to a ways to map this to another running app ?

I don't know a tool to do that directly. If you run xrestop, you may be able to figure out which app created that window, by looking at the resource id ranges.

And the winner is:

*drum rolls*

imsettings-applet!



imsettings-0.105.1/imsettings/xsettings-manager.c:158

  XSetSelectionOwner (display, manager->selection_atom,
		      manager->window, timestamp);

Thanks for catching up the unpredictable order for session management between gnome-session and XDG autostart. Though imsettings-applet enables XSETTINGS manager only when no XSETTINGS manager is running and usually g-s-d should be running before looking at XDG autostart dir.  You could disable that feature manually to avoid that entirely with:

$ gconftool-2 -s -t string /apps/imsettings-applet/xsettings_manager disabled

I'm pondering to disable it from the command line and have different .desktop files for GNOME/XFCE and others with OnlyShowIn and NotShowIn. and put one for GNOME into /usr/share/gnome/autostart which may be reliable a bit more than /etc/xdg/autostart for GNOME.

Fixed in imsettings-0.105.1-2.fc10. the instance of XSETTINGS manager won't be no longer created for GNOME/XFCE anyway.

Can we _please_ nuke any remnants of rogue xsettings manager from input methods ?

Nobody but the desktop environment itself has any business running xsettings managers.

Matthias, I'm afraid I don't see your point on using XSETTINGS. you said before when I asked you "what's wrong when imsettings doesn't work on the desktop not having the own XSETTINGS manager", "it's not a bug in the desktop but it's a mistake imsettings chose it to deliver the setting".  If the desktop itself has any business running XSETTINGS manager and something relates to XSETTINGS doesn't work, is it still a bug in the desktop itself then, isn't it?
As you know imsettings isn't any desktop-specific framework and I don't even think it should be nor is a good idea the desktop has similar code except UI/toolkit related work, since it doesn't depend on the desktops. so just provides a facility to get it working for the desktops which doesn't have, since there are no common implementation of XSETTINGS manager (not for the desktop config) and all the desktops implementation doesn't necessarily have one. otherwise immodule selection behavior is unpredictable without it.

Though we had discussed about a common implementation of XSETTINGS manager before, but I don't still see why not. my understanding is, XSETTINGS itself doesn't depend on any configuration library. we could still have different backends to reference them to XSETTINGS keys and the backends could be loadable dynamically. if one doesn't want/need gconf/GNOME related desktop config, they could stop loading. similarly I can provide a backend for imsettings for a common implementation of XSETTINGS manager then. this would makes GTK+/GNOME applications working on non-GNOME desktop as well as non-GTK+/GNOME applications on GNOME desktop, which uses XSETTINGS for their configuration say. and noone needs to reimplement XSETTINGS manager for their desktops and won't mind if duplicate instance is running on the desktop anymore. what's wrong with this idea?

xsettings are a mechanism to export a small set of common cross-desktop settings from a desktop-specific configuration system (like gconf, or kconfig, or whatever) in a desktop-neutral way for applications to use. 

XSettings are not something you just implement for yourself because you are afraid to commit to any concrete configuration system. 

This whole notion that the input method framework could be something that sits in splendid isolation from the desktop itself is something that doesn't work, and needs to be revisited. 

There is a growing concern on the desktop side about scim breaking the desktop experience for users _who don't even want input methods_.

This bug is just one example of our fragile input method framework of frameworks breaking the desktop.



Sorry for ranting.

FWIW, from a KDE packager point of view, while KDE doesn't currently have an xsettings manager (which is its own interoperability issue we'll want to fix eventually - there's an xsettings-kde for KDE 3, but it doesn't work properly in KDE 4), I also don't think imsettings should be the xsettings manager for KDE, because it does not and should not know any settings apart from input.

I understand the need to work around the lack of an xsettings manager in KDE for now, but in the long term this is a bad solution.

And as Matthias Clasen says, xsettings may not be the right thing to use in the first place.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping