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

StacktraceTop:gdk_x_error (display=0x9c7e320, error=0xbf940eac)
xkl_process_error (dpy=0x9c7e320, evt=0xbf940eac)
_XError (dpy=0x9c7e320, rep=0xa097060)
process_responses (dpy=0x9c7e320,
_XReply (dpy=0x9c7e320, rep=0xbf941020, extra=0, discard=0)

Thank you for your bug report, what videocard and driver do you use?

Sebastien, the retrace service marked my bug as a dupe from this.

I can reproduce the crash connecting an external monitor and changing views with FN + CRT/LCD.

This causes the g-s-d crash.

I believe this bug is really a dup from bug #390875 linked at upstream http://bugzilla.gnome.org/show_bug.cgi?id=572141

It seems the root cause is within libxklavier

In my case i'm using an Intel 965 card. One thing that brings my attention is that with Jaunty the external monitor is recognized by it's manufacturer's name and model, however with Karmic this is not the case.

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. You will need to run gnome-settings-daemon with "--no-daemon --sync" in GDB. This will greatly help us in tracking down your problem.

I don't think this one looks related to bug #390875 really. That bug is a combined libxklavier/Xorg issue which we fully understand now (and the xorg issue is fixed in Karmic now). This one is more likely a xrandr issue.

This is getting quite a few duplicates now. Could someone experiencing this bug please follow my instructions above to get a backtrace with the --sync option. Without it, we won't know for sure which call is generating the error, and any effort to fix it will therefore just be guess work and speculation. I've got no way to trigger the crash here.

Chris: see bug 388250, which I just reported with Apport, after having started gnome-settings-daemon with --sync. Hope this actually helps.

Oops - I meant: see bug 435432 for traces about that. Wrong copy/paste...

Unfortunately, this bug report is still missing a useful backtrace. From looking at the current trace, the 'minor_code = 7' is a clue that the call which triggers the error was XRRSetScreenSize, which doesn't match the call in the existing backtrace (XRRSetCrtcConfig). This means that the error actually occurred some time in the past, so the backtrace here isn't a lot of use.

Could someone who can recreate this issue please try to obtain a backtrace following my instructions in comment #7?

In addition to that, it would also be useful to have a look at what happens at the protocol level, by capturing some information using xtrace. In order to use xtrace, you first need to add the following line to the "[security]" section of /etc/gdm/custom.conf (creating one if it doesn't already exist):

"DisallowTCP=false"

Once you have done this, please log out and back in again (or better still, restart your computer to make sure you get a new X server instance with the required configuration).

Once you have logged back in, please do:

killall gnome-settings-daemon
xtrace -D:9 -d:0 -k 2>&1 | tee ~/xtrace.log #Replacing :0 with the number of your X display
DISPLAY=:9.0 gnome-settings-daemon

Then try to recreate the issue and attach the resulting log file to this bug report once gnome-settings-daemon has crashed.

Thanks

One more thing, please revert any changes made to your /etc/gdm/custom.conf after following my instructions. "DisallowTCP=false" reduces security, and you shouldn't run with it normally.

I believe bug #447431 is the same bug; I've provided a synchronous backtrace there. Chris, do you also need the xtrace output still?

This is SRUable and there is no fix available now, so removing RC blocker milestone.

This appears to be the same bug as bug #447431; marking that bug as the master, since that's where all the debugging information is going.