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

Bug #321041 reported by Jaemus on 2009-01-25
This bug affects 221 people
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Expired
Critical
X.Org X server
Fix Released
Medium
libxklavier (Ubuntu)
Medium
Chris Coulson
xorg-server (Ubuntu)
Medium
Unassigned

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

Related branches

Hew (hew) wrote :

Confirmed based on duplicates.

Changed in gnome-settings-daemon:
importance: Undecided → Medium
status: New → Confirmed
Pedro Villavicencio (pedro) wrote :

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

Hew (hew) wrote :

Submitted upstream

Changed in gnome-settings-daemon:
importance: Undecided → Unknown
status: New → Unknown
status: Confirmed → Triaged
Pedro Villavicencio (pedro) wrote :

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.

Sebastien Bacher (seb128) wrote :

could somebody having the issue provide the requested information?

Michael Flaig (mflaig) wrote :

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

Changed in gnome-settings-daemon:
status: Unknown → Incomplete
Stéphane Marguet (stemp) wrote :

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

Sebastien Bacher (seb128) wrote :

could you get a stacktrace then?

Stéphane Marguet (stemp) wrote :

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

Stéphane Marguet (stemp) wrote :

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

Hew (hew) wrote :

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

demizer (jeezusjr) wrote :

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

Hew (hew) wrote :

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

Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → Incomplete
Stéphane Marguet (stemp) wrote :

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

Hew (hew) wrote :

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.

Changed in gnome-settings-daemon (Ubuntu):
status: Incomplete → Invalid
Changed in gnome-settings-daemon:
status: Incomplete → Invalid
Changed in gnome-settings-daemon:
status: Invalid → New
cazacugmihai (cazacugmihai) wrote :

I've got this error too on Ubuntu 9.10.

rohdef (krdata) wrote :

I have this one on 9.10 too.

Mark Nevill (nevillm) wrote :

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

Changed in gnome-settings-daemon (Ubuntu):
status: Invalid → New
Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
status: New → Triaged
Christopher (soft-kristal) wrote :

Karmic -15 crashed on startup.

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

Chris Coulson (chrisccoulson) wrote :

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

Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → Incomplete

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

Vish (vish) on 2009-08-17
tags: added: regression-potential
Chris Coulson (chrisccoulson) wrote :

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

Chris Coulson (chrisccoulson) wrote :

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.

Kimon Hoffmann (doctorrockit) wrote :

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...

Chris Coulson (chrisccoulson) wrote :

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).

Chris Coulson (chrisccoulson) wrote :

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 ;)

Chris Coulson (chrisccoulson) wrote :

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.

Chris Coulson (chrisccoulson) wrote :

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?

Dominik George (natureshadow) wrote :

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

Created an attachment (id=28963)
Don't return BadMatch from GetProperty

I've recently been investigating an application crash caused by an unhandled BadMatch error from XGetWindowProperty. BadMatch is not mentioned as a valid error from this call in the xlib documentation, so I'm unsure of whether this is a documentation bug, or a bug in xorg itself.

I did some debugging, and the BadMatch is returned from dixLookupDrawable() in dix/dixutils.c, because the returned drawable has type mask M_DRAWABLE_PIXMAP rather than M_WINDOW.

What seems to be happening in the client application is that it stores a pointer to some Window. This Window is then destroyed (but the client doesn't notice it), and at some point in the future, the client application calls XGetWindowProperty with the pointer to the Window that was destroyed earlier. However, I don't really understand why dixLookupResourceByClass() finds a valid drawable, seeing as the window was destroyed earlier. My Xorg knowledge is quite limited, but perhaps some other client created a pixmap that has the same ID as the window that got destroyed earlier.

Anyway, regardless of what is happening, the Window that the client passes to XGetWindowProperty is not valid, and I would have expected it to return a BadWindow error ("A value for a Window argument does not name a defined Window").

I've attached a patch which makes this call return a BadWindow error under these conditions, although I don't know if it is correct as this may still be a documentation error.

Chris Coulson (chrisccoulson) wrote :

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

Changed in xorg-server (Ubuntu):
importance: Undecided → Low
status: New → Triaged
importance: Low → Medium
Chris Coulson (chrisccoulson) wrote :

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

affects: gnome-settings-daemon (Ubuntu) → libxklavier (Ubuntu)
Changed in libxklavier (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Chris Coulson (chrisccoulson)
status: Incomplete → In Progress
Changed in xorg-server:
status: Unknown → Confirmed

Fix pushed as f04fe06ae244b851b38be824b1a80f2f8a030591. Not quite the one from here though but the end result is the same. Thanks for reporting,.

Bryce Harrington (bryce) on 2009-09-02
tags: added: jaunty
Changed in xorg-server:
status: Confirmed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in xorg-server (Ubuntu):
status: Triaged → Fix Released
valerio (valerio-orlandini) wrote :

Happened to me with Karmic AMD64

tags: added: regression-release
removed: regression-potential
Anthony Hook (anthonyhook) wrote :

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.

Peter P. (peter-p-launchpad) wrote :

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

Chris Coulson (chrisccoulson) wrote :

The libxklavier part of this bug is fixed in Lucid

Changed in libxklavier (Ubuntu):
status: In Progress → Fix Released
Bordi (borderlinedancer) wrote :

Affect me in lucid amd64 with virtualbox and nvidia pc.

Anzenketh (anzenketh) wrote :

Bordi Did you run your dist upgrades?

Don Forigua (ingforigua) wrote :

Affect me in maverick i386

Sundberg Pauli (susundberg) wrote :

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

Embridioum (embridioum) wrote :

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

Changed in xorg-server:
importance: Unknown → Medium
Changed in gnome-settings-daemon:
importance: Unknown → Critical
Changed in gnome-settings-daemon:
status: New → Expired
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
To post a comment you must log in.