|Summary:||There is hard(?) limit on a number of types.|
|Product:||xorg||Reporter:||Sergey V. Udaltsov <svu>|
|Component:||Server/Input/XKB||Assignee:||Xorg Project Team <xorg-team>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||medium||CC:||leonard, peter.hutterer, stephan|
|i915 platform:||i915 features:|
Description Sergey V. Udaltsov 2010-05-05 13:46:45 UTC
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.
Comment 1 Sergey V. Udaltsov 2010-05-05 13:47:58 UTC
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
Comment 2 Sergey V. Udaltsov 2010-05-05 13:49:33 UTC
$ 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);
Comment 3 Peter Hutterer 2010-05-05 15:37:57 UTC
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.
Comment 4 Sergey V. Udaltsov 2010-05-06 15:46:37 UTC
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.
Comment 5 Sergey V. Udaltsov 2010-05-06 15:47:10 UTC
Created attachment 35474 [details] valgrind output
Comment 6 Sergey V. Udaltsov 2010-05-06 15:48:35 UTC
Please note, some valgrind complains are related to xkb!
Comment 7 Peter Hutterer 2010-05-18 18:53:20 UTC
(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.
Comment 8 Daniel Stone 2010-05-20 14:27:46 UTC
(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.
Comment 9 Sergey V. Udaltsov 2010-06-26 08:29:02 UTC
> 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.
Comment 10 Sergey V. Udaltsov 2010-06-26 08:29:43 UTC
Created attachment 36520 [details] new valgrind output
Comment 11 GitLab Migration User 2018-12-13 18:39:08 UTC
-- 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.