gnome-settings-daemon crashed with signal 5 in xkl_process_error()

Confirmed based on duplicates.

this needs to be send upstream to bugzilla.gnome.org leaving an upstream task open.

Submitted upstream

comment from upstream:

"You need to get one of the users to run gdb --args .../g-s-d --sync
then break in gdk_x_error, and post the result of a "bt full". The output of
--debug might be helpful, too.
"

could someone provide that information? thanks in advance.

could somebody having the issue provide the requested information?

I'll have a look into it at the weekend. But I haven't seen this bug for at least a week.

@Sebastien : For me it's always crashing on startup (when starting the first application).
And after that I can't reproduce the crash.

could you get a stacktrace then?

After installing the debugging symbols (and an update), I doesn't crash anymore.

And of course, one restart later..... Crash, see Bug #340994 for traces.

Thanks for your help Stéphane. Please note the comment from upstream:

"You need to get one of the users to run gdb --args .../g-s-d --sync then break in gdk_x_error, and post the result of a "bt full". The output of --debug might be helpful, too."

We need this type of trace from gdb, with those parameters.

Note also that you are still missing debug symbols for the following packages:

libglib2.0-0
libgtk2.0-0
libxklavier12
libx11-6
libc6

I am getting this same error and it is killing me. I sent an error report using the reporting application. Thanks guys and gals!

I notice there hasn't been a duplicate report in a while. Does the problem still occur with Jaunty release?

No crash for me anymore, that's why I didn't post a trace ;)

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

I've got this error too on Ubuntu 9.10.

I have this one on 9.10 too.

I also got this in 9.10. Seems very out of the blue, probably hard to duplicate.

Karmic -15 crashed on startup.

Happens to me on Karmic constantly, like after every second login. Sometimes directly after login, sometimes a bit later.

Could somebody experiencing this bug and can recreate it easily please run the following in a terminal to try and get a more useful backtrace, as the one here does not have any useful information in it:

killall gnome-settings-daemon
gdb gnome-settings-daemon 2>&1 | tee gsd.log
break gdk_x_error
run --sync --no-daemon

When it breaks, please run "bt full" to obtain a backtrace. This will also break on normally handled exceptions, which are perfectly ok. To make sure that the error you just caught wasn't a harmless handled exception, please run "cont" and see if it breaks again, or just aborts. If it aborts, then the trace you got is useful. If it breaks again, then please go through this cycle until it eventually aborts. The last trace is the useful one.

Please attach gsd.log to this report.

Karmic users will also need to do the following before trying to obtain a backtrace, because the media-keys plugin sets xlib to run asynchronously again when it loads, regardless if whether you specified the "--sync" option or not:

gconftool-2 -s --type bool /apps/gnome_settings_daemon/plugins/media-keys/active 0

Please also make sure you have the following packages installed before getting the backtrace: gnome-settings-daemon-dbgsym, libglib2.0-0-dbg, libgtk2.0-0-dbg, libc6-dbg, libxklavier12-dbgsym (jaunty), libxklavier15-dbgsym (karmic), libx11-6-dbgsym and libxi6-dbg

If you can only recreate the crash on login, then you will need to take a different approach. Edit /etc/xdg/autostart/gnome-settings-daemon.desktop and add "--sync" to the end of the "Exec" line. Log out and back in again. If it crashes, Apport will catch the crash and generate a crash report. Don't submit this one though- I would rather you attached the stacktrace to this report for now. The stacktrace should be complete without any processing from the retracer, seeing as you already installed the dbgsym packages I mentioned earlier. (If you do submit the crash report as a separate bug, please tell me the bug number).

To extract the stacktrace from your apport crash report, do the following:

mkdir gsd-crash
apport-unpack /var/crash/_usr_lib_gnome-settings-daemon.<uid>.crash ~/gsd-crash

(Obviously replacing "<uid>" with your user ID).

Once you have done this, there will be a file named "Stacktrace" in ~/gsd-crash. Please attach this. Then make sure you remove the "--sync" option from /etc/xdg/autostart/gnome-settings-daemon.desktop again.

Thanks

I experienced this problem this morning on karmic. I then did as Chris suggested, setting the gconf value, installing debug symbols and changing the setting to the .desktop file. When I logout/in or reboot I now no longer get a crash with g-s-d

I've got a stacktrace of this now. I thought that this error was still being reported asynchronously, but after some further debugging I'm absolutely confident now that it isn't, and the BadMatch error here is being triggered by a XGetWindowProperty call

I've also triggered this error under xtrace (log attached). The interesting parts are:

000:<:0652: 24: Request(20): GetProperty delete=false(0x00) window=0x00400004 property=0x27("WM_NAME") type=0x1f("STRING") long-offset=0x00000000 long-length=0xffffffff
000:>:0652:40: Reply to GetProperty: type=0x1f("STRING") bytes-after=0x00000000 data='xsplash'

-------

000:>:07e5:32: Reply to GetInputFocus: revert-to=PointerRoot(0x01) focus=0x02e00004
000:<:07e6: 24: Request(20): GetProperty delete=false(0x00) window=0x02e00004 property=0x27("WM_NAME") type=0x1f("STRING") long-offset=0x00000000 long-length=0xffffffff
000:>:07e6: Event PropertyNotify(28) window=0x000000fc atom=0xf1("_NET_ACTIVE_WINDOW") time=0x00404b8a state=NewValue(0x00)
000:>:07e6:48: Reply to GetProperty: type=0x1f("STRING") bytes-after=0x00000000 data='System Monitor'
000:<:07e7: 4: Request(43): GetInputFocus
000:>:07e7:32: Reply to GetInputFocus: revert-to=PointerRoot(0x01) focus=0x02e00004
000:<:07e8: 24: Request(20): GetProperty delete=false(0x00) window=0x00400004 property=0x15f("XKLAVIER_TRANSPARENT") type=0x13("INTEGER") long-offset=0x00000000 long-length=0x00000001
000:>:7e8:Error 8=Match: major=0, minor=20, bad=4194308
000:>:07e8: Event PropertyNotify(28) window=0x01c00003 atom=0x13f(unrecognized atom) time=0x00404c69 state=NewValue(0x00)

I've only so far seen this error when XGetWindowProperty is called on the xsplash window, which is really wierd. Also, BadMatch is not documented in xlib as a valid error from this xlib call.

I'm experiencing the same problem since Jaunty, and in my case the crash always linked to starting either Firefox or Thunderbird, although it does not happen every time one of these applications is started (~3 out of 5 times in Jaunty, ~1 out of 15 in Karmic Alpha 4).

This problem occurs on two systems, which are sort of similar concerning their hardware and their software configuration, one being a desktop computer with an Intel 945G chipset, the other one being a Netbook with the Intel 945GSE chipset.

Attached you find the crash report as generated by apport. The relevant excerpt from ".xsession-errors" always refers to the same error, as an example here is the relevant excerpt associated with the crash recorded in the attached file:

Gdk-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 14023 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.)
aborting...

Please don't attach crash files to bug reports. They're more difficult to work with, and they might also contain sensitive information (which everyone subscribed to this report can see).

And I don't need a backtrace for this bug report now (it's already got a good one). However, if someone can tell me why Xorg returns the BadMatch error, I will be eternally grateful ;)

I've done a little more debugging with this now. It seems to be triggered by something which happens when the window manager loads with xsplash already running. If I build xsplash with a call to gtk_window_set_decorated to turn off the decorations for xsplash, then the error goes away (although that might just be coincidence).

I stuck a debug hook in xorg to log a warning when this GetProperty request returns an error. The BadMatch is returned from dixLookupDrawable() in dix/dixutils.c, and the reason is that the type mask for the drawable is M_DRAWABLE_PIXMAP when it should have been M_WINDOW (the information logged shows this). Now I need to work out why this is the case.

I took a look at my xtrace log again, and I noticed that in the run-up to the BadMatch error, I see several (harmless) BadWindow errors from requests to the xsplash window. This suggests that the xsplash window no longer exists:

000:<:065c: 24: Request(20): GetProperty delete=false(0x00) window=0x00400004 property=0x11d("WM_STATE") type=0x11d("WM_STATE") long-offset=0x00000000 long-length=0x00000000
000:>:65c:Error 3=Window: major=0, minor=20, bad=4194308
----
000:<:065e: 8: Request(15): QueryTree window=0x00400004
000:>:65e:Error 3=Window: major=0, minor=15, bad=4194308

Sure enough, when I look a bit further up in the log-file, gnome-settings-daemon saw a DestroyNotify for the parent window of xsplash:

000:>:0658: Event UnmapNotify(18) event=0x000000fc window=0x01a00032 from-configure=false(0x00)
000:>:0658: Event DestroyNotify(17) event=0x000000fc window=0x01a00032

So, I wonder if the BadMatch is because some other process created a new window, and it has the same ID as the previously destroyed xsplash window?

I also see this in karmic, but can't reproduce it manually.

-nik

I've seen this issue running Karmic alpha 4 in a Virtualbox with compositing enabled.

Do you need additional traces? If so, what do you need?

Running under Karmic alpha 4 AMD64 in a Virtualbox with compositing enabled I also get bug 185785. Perhaps there is a relation?

Well, I could reproduce the bug with Karmic alpha 4 (i386) as my host OS
(outside of VirtualBox). I don't think that VirtualBox is a good trail, but
it's just my 2cents.

Regards,

Quentin

2009/8/26 Nikolaj Sheller <email address hidden>

> Running under Karmic alpha 4 AMD64 in a Virtualbox with compositing
> enabled I also get bug 185785. Perhaps there is a relation?
>
> --
> gnome-settings-daemon crashed with signal 5 in xkl_process_error()
> https://bugs.launchpad.net/bugs/321041
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in Gnome Settings Daemon: New
> Status in “gnome-settings-daemon” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: gnome-settings-daemon
>
> Just crashed out of nowhere... Was running terminal when it crashed.
> Running Ubuntu jaunty 9.04
>
> ProblemType: Crash
> Architecture: amd64
> DistroRelease: Ubuntu 9.04
> ExecutablePath: /usr/lib/gnome-settings-daemon/gnome-settings-daemon
> NonfreeKernelModules: nvidia
> Package: gnome-settings-daemon 2.25.3-0ubuntu1
> ProcCmdline: /usr/lib/gnome-settings-daemon/gnome-settings-daemon
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> Signal: 5
> SourcePackage: gnome-settings-daemon
> StacktraceTop:
> ?? () from /usr/lib/libgdk-x11-2.0.so.0
> xkl_process_error () from /usr/lib/libxklavier.so.12
> _XError () from /usr/lib/libX11.so.6
> _XReply () from /usr/lib/libX11.so.6
> XGetWindowProperty () from /usr/lib/libX11.so.6
> Title: gnome-settings-daemon crashed with signal 5 in xkl_process_error()
> Uname: Linux 2.6.28-5-generic x86_64
> UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
>

--
Quentin Lampin
06 70 55 41 34
Département Télécommunications
Insa de Lyon

Based on what I think is happening here now, I've forwarded a bug on to https://bugs.freedesktop.org/show_bug.cgi?id=23562

I still think there is a bug in libxklavier, in that it queries a window that was destroyed quite some time ago

This bug was fixed in the package xorg-server - 2:1.6.3-1ubuntu5

---------------
xorg-server (2:1.6.3-1ubuntu5) karmic; urgency=low

  * Add 185_dix_badwindow.patch: dixLookupWindow may return BadMatch if
    the window in question isn't actually a window. In this case,
    GetProperty needs to return BadWindow - not BadMatch. Fixes unexpected
    crash in some GNOME applications not expecting to get BadMatch returned
    from this function call.
    (LP: #321041)

 -- Bryce Harrington <email address hidden> Thu, 03 Sep 2009 18:27:04 -0700

Happened to me with Karmic AMD64

I am running Lucid Lynx 10.04 inside Virtualbox and I had resized my Virtualbox session window, Lucid changed it's resolution as it should but gnome-settings-daemon crashhed after.

Exactly the same here: Happened when switching Lucid Lynx 10.04 inside Virtualbox to full screen.

The libxklavier part of this bug is fixed in Lucid

Affect me in lucid amd64 with virtualbox and nvidia pc.

Bordi Did you run your dist upgrades?

Affect me in maverick i386

I think i hit this same bug while setting mixer input volume and then closed the setting dialog, 10.10 up-to-date, netbook remix, i386

Maverick beta here.
I did a partial update through manager, then restarted.
Upon login the screen blinked and I got this old-looking desktop.