The file types/level5 contains 2 extra types which are currently commented out. If these types enabled, X crashes. If any other types are commented - X is ok again. It does not matter if types are used or not.
This behaviour depends on some external aspects. For example, it manifests itself on Power G5 (Ubuntu 10.04) but not x86.
0: /usr/bin/X (xorg_backtrace+0x58) [0x100b57e8]
1: /usr/bin/X (0x10000000+0x6bce4) [0x1006bce4]
2: (vdso) (__kernel_sigtramp_rt32+0x0) [0x100370]
3: /lib/libc.so.6 (0xfe40000+0x17f0ac) [0xffbf0ac]
4: /lib/libc.so.6 (__libc_malloc+0x8c) [0xfec888c]
5: /usr/bin/X (Xalloc+0x38) [0x1006ce28]
6: /usr/bin/X (Xcalloc+0x30) [0x1006d1c0]
7: /usr/bin/X (SrvXkbResizeKeyType+0x794) [0x1013d834]
8: /usr/bin/X (0x10000000+0x11debc) [0x1011debc]
9: /usr/bin/X (0x10000000+0x11e93c) [0x1011e93c]
10: /usr/bin/X (0x10000000+0x2acc0) [0x1002acc0]
11: /usr/bin/X (0x10000000+0x1d3b4) [0x1001d3b4]
12: /lib/libc.so.6 (0xfe40000+0x1f73c) [0xfe5f73c]
13: /lib/libc.so.6 (0xfe40000+0x1f900) [0xfe5f900]
Segmentation fault at address 0x6d
Caught signal 11 (Segmentation fault). Server aborting
$ addr2line 0x1013d834 -e /usr/lib/debug/usr/bin/Xorg
which points to
This just indicates some memory corruption beforehand. Can you run Xorg through valgrind to figure out what's going on here?
I've tried this on 1.8 32 and 64 bit and 1.7 32 and 64 and couldn't reproduce it.
A couple of comments. This problem for some reason appears when I run X from gdm. If I start pure X - it just starts.
I replaced /usr/bin/X with the script:
echo "$@" > /tmp/valgrindX.log
exec /usr/bin/valgrind --trace-children=yes /usr/bin/X.orig "$@" 2>&1 | tee -a /tmp/valgrindX.log
In that case, I could not get neither crash, not gdm login screen (I waited for some while). But there are some issues, as valgrind thinks.
Created attachment 35474 [details]
Please note, some valgrind complains are related to xkb!
(In reply to comment #4)
> A couple of comments. This problem for some reason appears when I run X from
> gdm. If I start pure X - it just starts.
could just be that gdm applies the groups, plain X doesn't. If you run setxkbmap after starting a plain X server it works fine?
> I replaced /usr/bin/X with the script:
> echo "$@" > /tmp/valgrindX.log
> exec /usr/bin/valgrind --trace-children=yes /usr/bin/X.orig "$@" 2>&1 | tee -a
try without --trace-children, that may be the reason for the hang you described in an email (just guessing though). the valgrind output without the crash won't be too useful as we're looking for memory corruption before the crash.
(In reply to comment #6)
> Please note, some valgrind complains are related to xkb!
They're all from MakeAtom though (note the same also happens coming from radeon_drv and evdev), so are almost certainly unrelated. I'd be inclined to copy the type-copying code in _XkbCopyClient, which is unpleasant and probably wrong.
> try without --trace-children, that may be the reason for the hang you described
> in an email (just guessing though). the valgrind output without the crash won't
> be too useful as we're looking for memory corruption before the crash.
First of all, some upgrades of x server/drivers were performed by ubuntu. Still, gdm hangs with extra types.
Tried the same valgrind script without --trace-children. Still could not get anything on the screen, it stays blank. This time no complains from valgrind at all. See attached.
Created attachment 36520 [details]
new valgrind output
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/310.