I've been repeatedly hit with a crash bug in the past month. It was occuring apparently randomly (not on startup, not easily correlating to any of my actions) and the result was an X crash. The only thing I could see is that most of the time, the last line in Xorg.log was reading:
[xkb] BOGUS LENGTH in write keyboard desc, expected 5940, got 5956
(exact numbers were different each time)
(sometimes I had this line present multiple times in the logs)
After noticing a higher occurence of the crashes when using VMWare (more than once per day) and learning how to properly use gdb with X I was finally able to obtain a few clean traces.
Program received signal SIGABRT, Aborted.
0xffffe424 in __kernel_vsyscall ()
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb7c9b640 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7c9d008 in *__GI_abort () at abort.c:88
#3 0xb7cd8e1d in __libc_message (do_abort=2, fmt=0xb7db3188 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#4 0xb7cdf1d4 in malloc_printerr (action=2, str=0xb7db3260 "double free or corruption (out)", ptr=0xa153350) at malloc.c:5994
#5 0xb7ce1186 in *__GI___libc_free (mem=0xa153350) at malloc.c:3625
#6 0x08136241 in Xfree (ptr=0x0) at ../../os/utils.c:1165
#7 0x081903c1 in XkbSendMap (client=0x9f1e7a0, xkb=0xa0cd2c8, rep=0xbfe034e8) at ../../xkb/xkb.c:1409
#8 0x0819400c in ProcXkbGetKbdByName (client=0x9f1e7a0) at ../../xkb/xkb.c:5807
#9 0x0819a8f8 in ProcXkbDispatch (client=0x6) at ../../xkb/xkb.c:6690
#10 0x0808c7ff in Dispatch () at ../../dix/dispatch.c:437
#11 0x080719dd in main (argc=9, argv=0xbfe03734, envp=Cannot access memory at address 0xf33) at ../../dix/main.c:397
Program received signal SIGSEGV, Segmentation fault.
#0 0xb7c28b98 in _int_free (av=0xb7d15140, mem=0x9464988) at malloc.c:4726
#1 0xb7c29186 in *__GI___libc_free (mem=0x9464988) at malloc.c:3625
#2 0x08136241 in Xfree (ptr=0xa517d) at ../../os/utils.c:1165
#3 0x081903c1 in XkbSendMap (client=0x92521a0, xkb=0x907a4f0, rep=0xbfc49f48) at ../../xkb/xkb.c:1409
#4 0x0819400c in ProcXkbGetKbdByName (client=0x92521a0) at ../../xkb/xkb.c:5807
#5 0x0819a8f8 in ProcXkbDispatch (client=0x50d517c) at ../../xkb/xkb.c:6690
#6 0x0808c7ff in Dispatch () at ../../dix/dispatch.c:437
#7 0x080719dd in main (argc=9, argv=0xbfc4a194, envp=0x50d517c) at ../../dix/main.c:397
(traces were obtained using xorg-server-1.6.1, debian packages xserver-xorg-core 2:1.6.1-1 )
You can see that these two traces correspond to the same piece of code (Xkb), which show that the error in the log is actually related to the crash. The outcome is not always the same though (abort or segfault).
The crash happens at the xfree((char *)start) in the end of XkbSendMap .
possibly related : #16458
Created attachment 25861 [details]
i've had this also, very annoying. happens to me when loading oowriter.i've been unable to get a backtrace so far.
I can confirm this as well — happens sometimes when loading oowriter. The backtrace I get in Xorg.0.log corresponds to what's said in the first comment. In my case, the difference between the two numbers is 16 as well.
I will try to apply the following quickfix, which I think may prevent the server from crashing (but the error is somewhere else, of course):
@@ -1366,7 +1366,7 @@ unsigned i,len;
- start= desc= (char *)xalloc(len);
+ start= desc= (char *)xalloc(len + 128);
if ( rep->nTypes>0 )
I will report later.
Okay, I can confirm that the patch prevents the X server from crashing. I will further investigate what causes the length to be bigger.
I can confirm regularly seeing this problem in Ubuntu Intrepid and Jaunty.
Created attachment 26038 [details] [review]
Okay, I believe the attached patch fixes this issue properly.
*** Bug 16458 has been marked as a duplicate of this bug. ***
*** Bug 6428 has been marked as a duplicate of this bug. ***
Pushed as 525aa17f804d37d1cfcbbf6b8e6cddb45e999b20. Thanks for your time and the patch, it is much appreciated.
Thanks for solving this problem. I am also severely hit by this bug. The only question:
How do we, end users, apply the patch? I am using openSuSE 11.1 with X.Org X Server version 1.5.2 (released on 2008.10.10) installed. Should I just wait till openSuSE releases a patched X Server via their update repositories? Or should I manually get the sources, apply the patch and compile the X server myself?
You could file a bugreport into their bugzilla and have them include this patch in an update, but if you're experiencing the problem every other day, it may be better to apply it yourself.
I think the easiest way is grabbing the source package for xserver for your distribution (http://en.opensuse.org/Zypper/Usage#Source_Packages_and_Build_Dependencies), applying the patch (RPM specfiles aren't difficult, but it's more than just doing patch -p1) and building that with rpmbuild.
(In reply to comment #12)
> You could file a bugreport into their bugzilla and have them include this patch
> in an update, but if you're experiencing the problem every other day, it may be
> better to apply it yourself.
> I think the easiest way is grabbing the source package for xserver for your
> applying the patch (RPM specfiles aren't difficult, but it's more than just
> doing patch -p1) and building that with rpmbuild.
Thanks for your reply, Tomas! Do you know, in what version of X server will this patch be already included?
Say, will it be enough to just recompile the core X server, or should I rebuild all the modules/drivers as well?
(In reply to comment #13)
> Thanks for your reply, Tomas! Do you know, in what version of X server will
> this patch be already included?
Nope, but I think this patch should be nominated for inclusion in server-1.6-branch — that would mean distributions shipping xserver 1.6 would pick it up soon.
> Say, will it be enough to just recompile the core X server, or should I rebuild
> all the modules/drivers as well?
Core xserver is the only thing you need to patch and build.
> Nope, but I think this patch should be nominated for inclusion in
> server-1.6-branch — that would mean distributions shipping xserver 1.6 would
> pick it up soon.
I agree, please add the nomination to the wiki page.
*** Bug 20081 has been marked as a duplicate of this bug. ***
FTR, patch is now in 220.127.116.112.