Bug 27988 - There is hard(?) limit on a number of types.
Summary: There is hard(?) limit on a number of types.
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: 7.5 (2009.10)
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-05 13:46 UTC by Sergey V. Udaltsov
Modified: 2018-12-13 18:39 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
valgrind output (73.85 KB, text/plain)
2010-05-06 15:47 UTC, Sergey V. Udaltsov
no flags Details
new valgrind output (40.36 KB, text/plain)
2010-06-26 08:29 UTC, Sergey V. Udaltsov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.