Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  IRIS XallocColorCells failure
Message-ID: <9103090211.AA24250@lightning.McRCIM.McGill.EDU>
Date: 9 Mar 91 02:11:11 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 73

> I've just made my first tentative steps into the X world, and this
> first foray hasn't exactly been the most fun-filled escapade of my
> life, at least thus far.

Don't worry - it gets better. :-)

> First, the background:  I've taken on the somewhat unenviable task of
> porting a moderately large [...] software package to the IRIS.
> [...rather than port the graphics level, just use the X support...]

> The window gets created as expected, but one routine
> (XAllocColorCells) returns zero when the server starts up.  Then,
> when the client program tries to talk to the server, the server bombs
> out, saying:

> X Error of failed request:  BadAccess (attempt to access private resource denied)
>   Major opcode of failed request:  89 (X_StoreColors)

According to the protocol document, in the description of the
StoreColors request:

	[A]n Access error is generated if a specified pixel is
	unallocated or is allocated read-only.

The Xlib document contains similar wording.  This is more or less to be
expected, because you say XAllocColorCells returned 0, which indicates
failure.  It strikes me as rather badly written of the client to not
even bother checking whether XAllocColorCells succeeded!

> I've sniffed around with dbx far enough to discover that this happens
> when XPending gets called, but *only* when it's called after a bunch
> of other Xlib routines get called.

The error is detected on the server; it's just that Xlib doesn't notice
the error event until the next time it tries to read from the X
connection, which is only in the call to XPending where you noticed it.

> The XAllocColorCells failure, plus the reference to a "private
> resource" in the error message, lead me to believe that something
> about SGI's implementation of X makes color cell allocation
> impossible (or privileged).

What does xdpyinfo produce?  It may be that the only visual available
is a static one (StaticColor or TrueColor (or StaticGray, but that
seems unlikely)).  It is also possible that a dynamic visual is
available, but that the default is a static one and the program isn't
bothering to check.

> Note that this server (allegedly) works just fine under other
> vendors' versions of X, though I haven't actually tested that yet.

There are a great many programs, I am discovering, which make
unwarranted assumptions that work enough places that it takes a while
for anybody to notice the brokenness.  One example that came up today
is that xtank assumes that anything deeper than one bitplane is a color
server; this breaks on the NeXT.  Your program apparently assumes that
the server always has sufficient writable colormap room available; this
will break on static-visual-only servers or, if it is stupid about
searching for visuals, those with static default visuals.

> To ask the time-honoured question, is this a bug or a feature?

Almost certainly a bug in the program - not checking XAllocColorCells'
return value, if nothing else.  As to SGI's server, it could be a bug
but I think more likely it's a feature.  Their server probably reports
something close to what their hardware does, which is as it should be.
(I say it could be a bug because you haven't given enough information
for me to be sure it isn't, though it does seem unlikely.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu