gregm@otc.otca.oz.au (Greg McFarlane) (11/22/90)
This has also been sent to xbugs.
X Window System Bug Report
xbugs@expo.lcs.mit.edu
VERSION:
R4
CLIENT MACHINE and OPERATING SYSTEM:
Any machine that cannot allocate ~1000M bytes of memory
DISPLAY TYPE:
N/A
WINDOW MANAGER:
N/A
AREA:
Xmu
SYNOPSIS:
When Xmu caches atoms it tries to allocate a chunk of memory equal
to the value of the largest atom it knows about. If the server returns
large values when non-predefined atoms are interned, this chunk of
memory can become so large that XtRealloc crashes.
DESCRIPTION:
The protocol document defines an ATOM as a 32-bit value whose
top three bits are guaranteed to be zero. Therefore a client or library
cannot assume that an atom will be a small number. However when
XmuInternAtom() caches atoms it uses an array indexed by the
value of the atom. This works if atoms are always small, but if the
value of the atom is large, the size of the array will become too big.
REPEAT BY:
If you have a server that uses large values for atoms (mine sets the
fourth-most significant bit), then run xterm and try to use the selection
mechanism to copy out of it.
If you don't have such a server, then look in mit/lib/Xmu/Atoms.c in
the function CacheLookup(). You will see the line
XtRealloc((char*)cache, ((int)atom+1)*sizeof(CacheEntry*));
If the value of atom is very large, XtRealloc fails.
FIX:
Use a different mechanism for caching atoms in Xmu.
--
ACSnet: gregm@otc.otca.oz.au
Greg McFarlane UUCP: {uunet,mcvax}!otc.otca.oz.au!gregm
|||| OTC || Snail: OTC R&D GPO Box 7000, Sydney 2001, Australia
Phone: +61 2 287 3139 Fax: +61 2 287 3299
$B%$%C%U(J $B%f!<(J $B%+%s(J $B%j!<%C%I(J $B%:%#%9(J $B!<(J $B%9%^%$%k(J