I also sometimes notice the long delay on login mentioned in the above bug, (basically the wallpaper loads then it just sits there doing nothing, then the panels come in). Not sure if it has anything to do with the gnome-settings-daemon though (sometimes the panels come in fine).

I have the following in xsession-errors:
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 1177 error_code 8 request_code 3 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.)

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

I tried killing and restarting gnome-settings-daemon after login about 20 times without any problems. It seems to only happen at boot (about 1 in 5 times?). So starting gnome-settings-daemon with gdb in the console won't cause the problem since it works fine after login.

In addition to that those instructions on the wiki don't actually work, installing the dbgsym package doesn't seem to actually replace the binary according to the md5sum of the binary and gdb reports no symbols. No error is shown during the install, I tried with a normal apt-get, one that specified the version as shown in the wiki and through synaptic. I can't uninstall the non-debug version without it trying to remove most of Gnome.

On my laptop running Ubuntu Lucid, my findings is that the problem always occur upon wake-up (resume) process, after I have moved my laptop (while in sleep mode) from one wi-fi area (e.g.: home) to another wi-fi area (e.g.: work), i.e. when network-manager has to change the connection to the newly available pre-registered SSID (which often fails). Then, all the gtk apps revert back to to default (ugly!) gtk theme. In order to get the ambiance theme back, I have to open the theme applet. The problem doesn't seem to happen otherwise.

I tried to got the debug output doing the modification of the attached patch, but the trouble doesn't appears doing this (at least for the 5 tries I made since this). Maybe others will success in doing this.

My idea is that there is a race condition between dbus and g-s-d that prevent g-s-d to start if dbus isn't totally ready, but I can't prove it, and I don't now how to log the startup of dbus and g-s-d.

Some precisions:
- if g-s-d still doesn't start after applying the modification I added, errors will be traced in ~/.xsession-errors file.
- if g-s-d start after applying the modification I added, I think this is because the computation of log(s output take some time and 'slow down the startup of g-s-d. This may be the sign of the race condition that I suspect, but it will be harder to debug.

To summarize that thread, when multitasking for an hour or so, the gnome theme reverts to the default. It doesn't always happen, but it is happening pretty regularly to me and the other users in that thread. Opening System->Preferences->Appearances then causes the theme to change back to whatever the user had previously set it to, except for the icons (they remain set to the default theme). The following error message showed up in syslog:

Since the settings daemon starts when the gnome session starts, I tried to do a backtrace by using Ctrl-Alt-F2, starting X on dislpay :1, and running a second gnome session under gdb. After seeing the bug behavior, I killed the session in the terminal, entered "bt" at the gdb prompt, and got the following:

I removed the sun-java6-plugin package, thinking it was the source of the problem, but I continued to see random theme changes. Then I stopped using Gnome-Do/Docky and went back to using the regular Gnome panel. Since then, I haven't seen any random theme changes. My new plan is to begin using Gnome-Do/Docky again to try and recreate the bug.

If successful, then I think the bug can be safely narrowed down to the Gnome-Do/Docky package.

>>"I've seen this bug on a machine that doesn't have gnome-do/docky installed."

That makes me a little sad, because I was really hoping I had narrowed the problem down, but it's helpful nonetheless.

After re-reading this thread, I'm starting to wonder if maybe mine is a different bug. OP's report describes an error occurring at startup, but my bug's symptoms occur well after startup. I originally thought these were related as gnome-settings-daemon errors, but maybe I'm wrong.

My new hypothesis is that some program sends a message to the X-server to redraw/update a window while several programs are running. In order to redraw/update the window, the settings daemon must supply theme, font, color, and other settings. The gnome-settings-daemon then crashes due to lack of available resources, poor process scheduling, or some other problem, and lacking settings info, the X-server reverts to the default theme. In my case, docky was at least related to the crashes-- the symptoms went away when I stopped using it-- but I'm unsure how it was causing them.

I don't have the expertise to explore this line of reasoning, nor do I have the knowledge to determine if this is sound logic. What would be nice is if some code guru out there in Launchpad Land could investigate this bug a little bit.

I spoke too soon in declaring the bug squashed. I had some trouble printing a document, fiddled with CUPS, tried to see the print queue via System->Administration->Printing, and then saw my theme revert to the default theme.

The printer I was using is a network printer, and it worked fine this morning. Between then and the failure to work, there were no major changes to my system. I'm still using the regular gnome panel instead of Docky, and I haven't re-installed the sun-java6-plugin package that I first thought was the source of the problem.

I just posted a little more detail in the other thread (the link is in posts #9 and #10 ITT), but basically, I'm thinking this could be due to using older hardware. I'm using a 5 year-old Sony Vaio PCG-K45 with 3.2 GHz P4 and 1 Gb of RAM. Has anyone seen this bug on a computer that was built within the last year?

This problem keeps appearing for me since yesterday. Just as in the bug description, when I log in, sometimes the ambiance theme doesn't load and I get the default GTK-Theme instead. I have to either log out and log back in or start the appearances window to solve this annoying issue.
Also, even tough I don't know whether this is normal or not (I usually don't fiddle around with appearance settings, but use the defaults instead), when I'm selecting ambiance, after restart or log in-log out it is set to "custom". Again, I have no clue if this is relevant.
I'm using Ubuntu 64bit desktop edition on an Asus EeePC 1005PE.

In my case, bug started to showup after adding ru.png & us.png images for keyboard indicator in /usr/share/pixmaps. As I think now, where may be a problem with gnome / ubuntu indicator applets. Still checking...

i Think this bug is not related with any program like, Java6, Gnome-Do/Docky or what so ever. I Think this because the bug just happened after a system update of last week. That update cycle only contains update of the standard Ubuntu software source. I don know which one is causing the problem.

I tried several things like reinstalling all packages that contains "gtk¨ and that helped only within this session after the reboot it resets itself back to the buggy default gnome theme.

I am no master of this stuff but I am trying my best to help you people who can.

I actually think we are seeing a few different bugs that all result in gnome-settings-daemon crashing.

The bug I originally reported, which happened to me on 2 separate computers, with very different hardware (other than the fact they where both x86_64 installs), seemed to stop occurring on both systems. I'm guessing some update rolled out that fixed it. I have had almost no problems with gsd since then.

In my original case there was no gnome-do, docky, sun-java6 or any other programs other than the defaults. I don't think those would cause any problems since afaik gsd is just for giving settings to applications, it doesn't really care what the settings are.

The main problem is that there isn't any way to get debugging output of gnome-settings-daemon-dbgsym if it crashes at login making reporting bugs close to impossible.

gdb does support attaching to an already running process. Perhaps it's possible to use a script in a loop that keeps looking for it running and tried to attach then dump a backtrace somewhere (or runs in a screen so you can get the backtrack yourself)? If you getting crashing some time after login then it should be no problem to attach.

Just /etc/init.d/gdm stop, ctrl+alt+f2 to virtual terminal. Execute the above as root (it would probably be easier to save it to a script file first and run from that, it also might be worth while running it in a 'screen' session so you can attach to it from within a Xorg terminal). Then restart gdm. After gnome-settings-daemon crashes, ctrl+alt+f2 back to the VT and take a screen dump.

The bug just returned for me on Maverick. As a result, I'm going to remove it now, and never use it again. Instead I'm going to use my Lucid install (which doesn't show the symptom) whenever I want to use Ubuntu. I'll be back for Natty if the problem somehow magically resolves itself by then or someone finally looks into it. Unfortunately, those are big ifs. Until then I'm going to find another up-to-date Gnome/Linux distro for my main OS.

In maverick I have had this bug happen to me on several occasions on boot up. logging out and logging back in fixes the problem.
I have noticed this only happens to me after updating but only after an update where it say ureadahead will be re-profiled at next
boot up . Since noticing this every update that forces re-profiling has caused this problem but only on my pc and not my laptop.
PC uses nvidia driver 260.19.06 while laptop uses ati driver.

From what I can see, the current ddeb dbgsym packages have the gnome-settings-deamon binary in them which for some reason they didn't when I tried back with Lucid which made getting a stack trace impossible.

Since they now seem to work, Grab the dbgsym version and give the instructions I gave for logging gnome-settings-daemon a go. I would but it's no longer happening to me.

If the other instructions don't work or you want a different way, It might also be possible to rename dbgsym version of the /usr/bin/gnome-settings-daemon binary and replace it with script containing something like:
screen -L gdb --eval-command='run' gnome-settings-daemon.therealfile

Yeah, it seems that way. But I don't think this is just in my case. I'm experiencing the exact behaviour discussed in this bug. Sometimes (not regularly, maybe on every 3rd or 4th start-up) right after logging-in the desktop appears with the gnome default-theme. There is no gnome-settings-daemon process any more. Maybe it's not a crash, but the daemon shouldn't exit anyway (especially not with exit code 1, which indicates a problem, doesn't it?). Isn't there a way to configure gdb to produce a stacktrace on program termination with exit codes other than 0?

charakteristika of the bug:
1. gnome-settings-daemon randomly fails to start after log-in resulting in the standard-gnome-look (symbols and color-scheme in gnome-panel and nautilus)
2. after starting the appearence-menue gnome-settings-daemon starts without any problems solving the panel-issue
3. nautilus on the other hand stays uneffected
4. logging out and again logging seemes to solve the problem

The problem first occured a few weeks ago, since then sporadiclly however since yesterday it occoures permanently. I ran a regular system-update yesterday. Due to var/log/dpkg.log the following packages were affected

I have it on both my 10.10 installations (one on a classic netbook and one a fujistu tablet). i have not seen it on my 10.04 laptop. in the 10.10 systems I am using the desktop interface as Unity is unusable. As with all other comments it is random at startup. Theme can be altered back by going to appearance but nautilus stays ugly. I do not think it is dropbox related as posted above since I have drop box on my laptop 10.04 that does not have the bug, and on my 10.10 netbook that does have the bug whereas the tablet running 10.10 has no dropbox but does have the bug. The bug occurred on the netbook after "upgrading" to 10.10

After not having seen this bug for a while, it finally appeared again and I got the backtrace (see attachment). I had the breakpoints set on exit and _exit as suggested by David. I hope this helps and someone can take a look at this soon. BTW the .xsession-errors showed the following error:

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 1355 error_code 8 request_code 3 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.)

If i may inquire... now, that Martin has provided a backtrace, is the problem being looked into by a developer now (as the bug is still set to unassigned)? I know these things take time, but some feedback of activity would have a calming effect on us folks experiencing the problem.

I've recently been seeing this happen across two different motherboards.

I hadn't seen it appear at all previously.

I'll wager that on some level this is a race condition. It occurred zero times with a quad core and about 50% of the time with my six core. This happened on identical hardware with the only difference being the processor.

I have this problem on an install of lucid from the original alternate ISO and upgraded from there, i386 on a P4 with ATI (Mobility). Compiz is working nicely but gnome-settings-daemon usually doesn't start. No problems on my natty desktop.

When logging in the gnome-setting-manager with gdm's pid is still active. This makes users gnome-settings-manager fail to start. After some time gdm's one finally exits and users is left with gray theme.

I have the same problem --- occasionally after reboot the theme is reverted from radiance to ambiance and icon theme to some ugly default. If I log in / log out then everything goes back, i don't have to do nothing in settings for it.

Description: After a different user (with a different appearance settings) hase logged in (and after it logged out), with my user the theme was with ugly icons and menu backgrounds and unity panel.

Workaround:
killall gnome-settings-demon
gnome-settings-demon &
# after these two command the panel and the menu background was OK
killall nautilus
# after the automatic restart of nautilus the icon theme was OK