gnome-settings-daemon crash opening any window: "BadWindow" X error under Xvnc

Disabling the "keyboard" g-s-d plugin eliminates the crashing.
Re-enabling the plugin crashes g-s-d as soon as any window is open or
closed.

Test with gconf-editor at /apps/gnome_settings_daemon/plugins/keyboard.

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

gdb backtrace attached.

According to the output log, it's not failing during the xrandr plugin, but rather during the keyboard plugin, and in particular in some of the xklavier function calls:

#3 0xb792dab6 in XGetWindowProperty () from /usr/lib/libX11.so.6
No symbol table info available.
#4 0xb63feda4 in xkl_engine_get_window_title (engine=0x809cd80, w=46137345) at xklavier_util.c:49
 type_ret = 3220340892
 format_ret = -1215886672
 nitems = 3220340872
 rest = 3220340840
 prop = (unsigned char *) 0xb788fff4 "\200N\003"
#5 0xb63fee1c in xkl_get_debug_window_title (engine=0x809cd80, win=46137345) at xklavier_util.c:118
 name = <value optimized out>
 sname = "NULL\000op\000ttings-daemon\000\000nel\000oard\000"
#6 0xb63f884d in xkl_engine_process_create_window_evt (engine=0x809cd80, cev=0xbff28258) at xklavier_evt.c:446
 __func__ = "xkl_engine_process_create_window_evt"
#7 0xb63f9434 in xkl_engine_filter_events (engine=0x809cd80, xev=0xbff28258) at xklavier_evt.c:52
 __func__ = "xkl_engine_filter_events"
#8 0xb641f449 in gsd_keyboard_xkb_evt_filter (xev=0xbff28258, event=0x806e158) at gsd-keyboard-xkb.c:282
No locals.

Not sure what the problem is, but it's not related to the recent xrandr changes, particularly since you report things work properly after disabling the keyboard plugin.

I can also report this problem and the same solution --disabling the keyboard plugin to gnome-settings-daemon made everything work smoothly.

Not sure what else I can do to help, or what else is needed to move bug from
"incomplete" status. Hoping this is a good start.

FWIW Xvnc under Hardy is abysmally slow and klunky compared to Gutsy. I
have no idea why the performance is so awful here. I can see the individual
GTK widgets being painted! Same hardware, same network, just upgraded the
OS. Hmm. Sorry for the off-topic thought; I'll scan to see if there are
other bugs on Xvnc related to performance.

I have the same problem here. And I've been using Xvnc with xinet.d in this way under Feitsy and Gutsy, the speed is acceptable. But with Hardy b4, just try to vnc to localhost:1 will like viewing the desktop remotely through WAN. So I believe there should be something wrong here.

Hope the porformance issue could be fixed in the final release.

I have the same problem, using Hardy Beta 5, updated to April 1st. Disabling the keyboard plugin on Gnome Settings Daemon fixes the crashes.
Is there any open bug about Xvnc performance?

Same problem here; same fix; same poor VNC performance. Mine is started by inetd, not xinetd.

I confirm that I'm seeing the exact same issues (Xtightvnc causing gnome-settings-daemon to keep crashing with BadWindow on new windows being mapped, and being restarted) with the same fix (disabling the keyboard plugin for gnome-settings-daemon), in addition to the other issue with TightVNC (keyboard layout issues, #108928). I'm running hardy using coLinux and have Xtightvnc started by gdm as its standard X server.

Oh yes, and as more than one person has noted, VNC performance is incredibly poor on hardy. In fact, in my case, it's so poor that gnome-settings-daemon takes long enough to start up that the first thing to appear is a grey blank window that later (in a minute or so) paints to reveal an error that gnome-settings-daemon failed to start (or, more likely, just timed out, since it's running when the desktop appears and killing it to force it to restart gets it working again). It takes that long for the GNOME panels and the background image to appear and for the desktop to become responsive.

Same slow performance here with x11vnc server. I can't comment on performance before hardy as I ran vino, but x11vnc is very slow. I also applied the fix but this did nothing to help with performance.

The "Slow VNC" thing everyone is noticing is actually NOT directly related to VNC. So trying new VNC servers/clients will not help, unfortunately.

I suspect that this slowness in my VNC sessions (and probably yours too) is coming from something in the Gnome session... Very likely gnome-settings-daemon..

if you edit your ~/.vnc/xstartup file (make sure it is executable) and have it JUST start an xterm and then from that xterm you launch nautilus and gnome-panel then everything works perfectly!! No slowdowns... ultra fast. As is should be! ;) As it was in Gutsy. So this is a potential workaround. I'm currently using it (even though it is a little bit of a hassle) until the main problem is fixed.

I believe that gnome-settings-daemon is causing the slowness because one time I logged in to a normal gnome session via vnc and gnome-settings-daemon failed to start and everything was fast, as it is supposed to be.

So if I were debugging this, I would start looking at gnome-settings-daemon. :) Let me know if I can be of more assistance.

Interesting findings.

To confirm the performance issue is caused by gnome-settings-daemon, I just run following test:

1. Ctrl + Alt + F1, login
2. X :1 -query localhost

Then a similar window appears like open a VNC session. In this X session, the performance is good.

So I guess it's a Xvnc <-> gnome-settings-daemon connection issue. Since the X11 codes for Xvnc is "older" than native Xserver codes in Ubuntu, there may be some API not supported in Xvnc. So I guess if the Xvnc code is compiled against a newer version of Xorg, we'll get a Xvnc server with better performance.

And do you guys open the VNC session with GDM? I don't have a good performance in GDM either, where I believe the gnome-settings-daemon is not started yet.

By the way, where I mean "VNC performance" is Xvnc, not x11vnc. They are 2 different programs. The performance of Xvnc is fine in Feisty or Gutsy, but not in Hardy. The performance of x11vnc won't be as good as Xvnc in theory, since it's started for the existing DISPLAY and need to track the change of windows in a higher level, which will be slower.

I have similar problems with vnc speed and the gnome-settings Daemon crashing. To stop the message I not only had to disable the keyboard plug in but the mouse plug in as well. The speed is still sluggish compared to Gutsy though.

[quote]By the way, where I mean "VNC performance" is Xvnc, not x11vnc. They are 2 different programs. The performance of Xvnc is fine in Feisty or Gutsy, but not in Hardy. The performance of x11vnc won't be as good as Xvnc in theory, since it's started for the existing DISPLAY and need to track the change of windows in a higher level, which will be slower.[/quote]

FYI, Not having this problem with gdm started x11vnc in Xubunut. Saw it in Ubunut but pretty much went away when I turned off the "visual effects" in the last tab of Preferences -> Appearence. -- Skip

Moving to confirmed, the gnome-settings-daemon problem is definitely there. Please no comments about performance related problems, file a new bug or find an existing bug about it.

Ok. On current hardy, the problem seems to be even more about the gnome-settings-daemon's mouse plugin than keyboard plugin. Unsetting apps -> gnome_settings_daemon -> plugins -> mouse -> active gives me themed VNC session already, but it gnome-settings-daemon crashes often when doing anything with the end result of it being disabled quite soonish. Unsetting keyboard -> active alone does not help at all, but unsetting also it in addition to mouse -> active seems to give me a stable, themed VNC session.

Tried http://gentoo-wiki.com/Talk:HOWTO_RealVNC,_TightVNC,_XF4VNC, http://ubuntuforums.org/showthread.php?t=122402&page=43, and then some, but most information seems outddated. The only change needed really for gnome-session & in .vnc/xstartup to work were disabling those mouse and keyboard gnome-settings-daemon plugins.

I experienced the same problem with gnome-settings-daemon using Xvnc (vnc4server 4.1.1+xorg1.0) with Ubuntu 8.04 desktop (all updates as at 15 June 2008). I found that disabling just the keyboard plug-in for gnome-settings-daemon, and logging in again, gave immediate relief.

For the other dimwits like me, you can stop searching for the '/apps/gnome_settings_daemon/plugins/keyboard' folder in the file system now. People are referring to a tree of settings that you can change using the 'gconf-editor' application. Run that application and untick the 'active' setting for 'keyboard'.

I had the same problems but the descripton of Aaron Roydhouse fixed my problems.. Thank you!

Following Aaron Roydhouse and others' suggestion, I found that disabling the mouse plugin fixed the error messages. keyboard plugin had no effect. However, disabling the mouse plugin messed with my key bindings in such a way that the system was unusable.

I've followed "Roydhouse" suggestions. The improvement is minimal compared to the performance seen in Gutsy which I had running for a year... and which was virtually undetectable on a 1Gb lan. With Hardy upgrade (which I'm totally regretting) on the same network setup this is one significant degradation to usability.

I have approximately the same crash here. It looks like the gsd-keyboard-xkb filter gets a CreateWindow notification event, but the window id isn't valid anymore (maybe the window already disappeared?), for an unknown reason. When the xklavier engine tries to get the Window's title property, it gets the BadWindow error:

#0 gdk_x_error (display=<value optimized out>, error=0x7fff588b82f0)
    at /home/dim/deb/gtk+2.0-2.12.9/gdk/x11/gdkmain-x11.c:623
#1 0x00007fab4e307b6d in _XError (dpy=0x6288c0, rep=0x778110) at ../../src/XlibInt.c:2905
#2 0x00007fab4e30f068 in _XReply (dpy=0x6288c0, rep=0x7fff588b83f4, extra=0, discard=0)
    at ../../src/xcb_io.c:417
#3 0x00007fab4e2edb3d in XGetWindowProperty (dpy=0x6288c0, w=37749790, property=39, offset=0,
    length=-1, delete=0, req_type=31, actual_type=0x7fff588b8508, actual_format=0x7fff588b8514,
    nitems=0x7fff588b8500, bytesafter=0x7fff588b84f8, prop=0x7fff588b84f0) at ../../src/GetProp.c:64
#4 0x00007fab43f9c8a7 in xkl_engine_get_window_title (engine=<value optimized out>, w=3)
    at xklavier_util.c:53
#5 0x00007fab43f9c905 in xkl_get_debug_window_title (engine=0x6288c0, win=3) at xklavier_util.c:122
#6 0x00007fab43f97359 in xkl_engine_process_focus_out_evt (engine=0x6288c0, fev=0x7fff588b8780)
    at xklavier_evt.c:336
#7 0x00007fab43f97a79 in xkl_engine_filter_events (engine=0x68e920, xev=0x3) at xklavier_evt.c:44
#8 0x00007fab445b8036 in gsd_keyboard_xkb_evt_filter (xev=0x3, event=<value optimized out>)
    at gsd-keyboard-xkb.c:282
#9 0x00007fab4fe7a14c in gdk_event_apply_filters (xevent=0x7fff588b8780, event=0x779740,
    filters=<value optimized out>) at /home/dim/deb/gtk+2.0-2.12.9/gdk/x11/gdkevents-x11.c:345
#10 0x00007fab4fe7b7f6 in gdk_event_translate (display=0x633110, event=0x3, xevent=0x7fff588b8780,
    return_exposes=0) at /home/dim/deb/gtk+2.0-2.12.9/gdk/x11/gdkevents-x11.c:896
#11 0x00007fab4fe7d142 in _gdk_events_queue (display=0x633110)
    at /home/dim/deb/gtk+2.0-2.12.9/gdk/x11/gdkevents-x11.c:2285
#12 0x00007fab4fe7d55e in gdk_event_dispatch (source=<value optimized out>, callback=0x3,
    user_data=0x0) at /home/dim/deb/gtk+2.0-2.12.9/gdk/x11/gdkevents-x11.c:2345
#13 0x00007fab4c2043d4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0x00007fab4c2076e5 in ?? () from /usr/lib/libglib-2.0.so.0
#15 0x00007fab4c207a05 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#16 0x00007fab50213f03 in IA__gtk_main () at /home/dim/deb/gtk+2.0-2.12.9/gtk/gtkmain.c:1163
#17 0x0000000000403949 in main ()

latest trace is a duplicate of bug 254671.

Okay, I've done some serious digging, and it looks like a window is created (in my case it's mostly gnome-screensaver), but it disappears *before* the CreateNotify goes out. This is because gnome-screensaver complains that it's already running, and immediately quits. Thus it doesn't seem to call XDestroyWindow, and apparently the events belonging to the window aren't ditched somehow.

Is anyone seeing these BadWindow errors when they're *not* under Xvnc ?

this is fixed in Intrepid with the 2.24.0 version of the package.

Pedro: Is there any way to get this fix into ubuntu-updates (not ubuntu-security) for Hardy 8.04 LTS? Although not a security issue, it is a significant enduser annoyance issue (the number of duplicate bug reports attests to that), and Hardy 8.04 is marked "LTS" indicating that it should be okay to stick with that release for a few years.

Not fixed in intrepid, even though stated in comment 26. See the file I'm attaching. With normal settings, Segmentation Fault is gotten just by starting gnome-settings-daemon. With the mouse plugin disabled, the BadWindow is gotten if any window/application is opened. With both mouse and keyboard plugins disabled, gsd starts and works fine.

Using vncserver and vinagre, both machines running intrepid. The upstream bug linked to seems to be about randr, not mouse/keyboard plugins.

Aaron Roydhouse's suggestion to disable the keyboard plugin also stopped my gnome-settings daemon from crashing. This is on an up-to-date hardy system and vnc4server.

I can confirm this on a fresh install of intrepid x86 with all the latest updates and vnc4server installed. It works fine under normal X but under Xvnc, gnome-settings-daemon crashes every time it tries to start. With nothing disabled, it segfaults when initializing the mouse plugin. After disabling the mouse plugin, it will get a BadWindow message as described above. Disabling the keyboard plugin in addition makes it run without a problem.

fixed upstream, thanks for reporting.

Is somebody still having this in jaunty? could someone comment on the upstream report then? thanks.

I updated to Jaunty and as of today's Jaunty (2/3/2009) I can replicate this problem on i386.

The good news is that the workaround still works as well.

Me too!

Still fails on Jaunty (2009-03-15) with Terminal Server Client (Xnest and Xephyr) unless the keyboard plugin is disabled.

-jh

the bug described there has been fixed according to the GNOME bug, if you still have an issue on jaunty better to open a new bug

I'm seeing the failures stop as of 4/02/2009.

I should be more specific - the session I'm starting with x11vnc via gdm (the KillInitClients = False trick documented elsewhere) keeps the settings daemon alive. It seems to still die under TightVNC server when started by xrdp.

still happening with jaunty - a real pity, lost a couple of hours with this old bug.

This is what I get when I launch gnome-settings-manager in a terminal window inside the vnc (vnc4server) session.

incidentally the VNC resolution i get is also wrong (800x600 all the time, ignoring the -geometry)

I haven't found any workaround for any of these two issues

The resolution not being configurable by the vnc client is expected I think. Xvnc and I assume vnc4server don't support xrandr so you can't change the resolution from what is configured on the server when the display is created. So I think that one is a limitation rather than a bug. You can make multiple virtual displays on the server, each at different resolutions to suit different client devices (netbook vs. laptop).

Pity g-s-m is still crashing on jaunty though!

This bug also happens when using a Freenx session (I will try it with VNC and x11vnc later today). The only side effect is that theming and icons display incorrectly. It has only recently started to happen so there may be a regression somewhere.
After logging into freenx and Typing gnome-settings-daemon returns the following:

** (gnome-settings-daemon:21810): WARNING **: Unable to start xrandr manager: unhandled X error while getting the range of screen sizes
The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadClass, invalid event class'.
  (Details: serial 155 error_code 133 request_code 131 minor_code 6)
  (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.)

Disabling the keyboard plugin stops the error and the themes load correctly.

Should I open a new bug for Jaunty or mark this one as new or do nothing?

mabawsa >> how did you exactly disable the keyboard plugin ?

Just forgot what I said....
Open gconf-editor and go to apps/gnome-settings-daemon/plugins/keyboard and disable it ;)
This bug has recently happened with Freenx session (since the last kernel update (2.6.28-14) actually) ...maybe you should open a new bug report ?

I have exaclty the same problem as mabawsa, with the themes not working in a FreeNX session. Disabling the keyboard plugin fixes the problem. This seems to be a regression that was introduced by an update that was released 1-2 weeks ago. Can't say exactly because I only noticed it after a restart. I'm also running Jaunty.

Please don't reopen old bugs that are fixed. If you're having issues, please open a new bug even if your symptoms are similar.

I have started a new bug report on this: Bug #409621