Logging into GNOME from GDM with my user causes X.org to segfault. This doesn't happen with a new user, just the old one. I've narrowed it down to a null pointer deref in xkbLEDs.c:67, but I'm not sure how to best fix it.
I've also reported with Ubuntu hardy, and a stack trace is available: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/180884
Please let me know if any more information is needed to solve this.
can you please post your configuration file? the input devices are of interest here.
the other thing that'd be interesting is if you can reproduce the crash in gdb, print out dev->name. this way we know which device causes the problem.
Created attachment 13786 [details]
configuration for my Toshiba Tecra M7 tablet
The wacom devices are present and working, and are the only nonstandard device I can think of.
After a bit of wrestling, I got xorg to debug again. The device is "eraser". Naturally, eraser has no LEDs, as it's part of a passive pen device!
(In reply to comment #3)
> After a bit of wrestling, I got xorg to debug again. The device is "eraser".
> Naturally, eraser has no LEDs, as it's part of a passive pen device!
please try the simple patch below. i think the correct fix would be in the caller but i don't know enough about XKB for that.
diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index 2877af0..55ce12a 100644
@@ -63,6 +63,9 @@ XkbSrvLedInfoPtr sli;
+ if (!sli)
+ return update;
After doing a bit more research, I've discovered reports in Debian's BugTracker that the latest wacom-tools doesn't trigger this. I'm now contemplating how to best go with this. It seems like there are cases where NULL can be received, so your patch is at least a step in the right direction for xkb. I'll see about perhaps building with the patch for Ubuntu (my testing system), but it'll probably take some time. If wacom-tools genuinely fixes the bug, then it's probably a good idea to lower the priority of this bug.
actually tracking down this problem is more of a nightmare than fixing the symptom.
pushed as d954f9c80348de294602d931d387e5cd1ef4b9a5
Any chance that this patch can also be pushed into the 1.4-branch?
(In reply to comment #8)
> Any chance that this patch can also be pushed into the 1.4-branch?
done. daniels pushed it as bc72ef3a159efd67067322c043bba444869dc356