Backtrace:
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
/build/buildd/xorg-server-1.7.6/build-main/xkb/../../xkb/XKBMAlloc.c:342

which points to

       type->level_names=_XkbTypedRealloc(type->level_names,new_num_lvls,Atom);

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]
valgrind output

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
> /tmp/valgrindX.log

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.