Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!bu.edu!icad!lcs
From: lcs@icad.icad.com (Larry Stone)
Newsgroups: comp.windows.x
Subject: Access error freeing allocated color cells on static visuals
Message-ID: <1990Dec19.080521.3381@icad.com>
Date: 19 Dec 90 08:05:21 GMT
Sender: lcs@icad.com (Larry Stone)
Organization: ICAD Inc., Cambridge, MA
Lines: 19

According to my understanding of the protocol spec and Xlib, any color
cell is allocated read-only with AllocColor, it can be freed by a
FreeColors request.  The only time FreeColors should issue an Access
error is when the pixel was not previously allocated by the same client.

I have some code that allocates color cells with AllocColor and later frees
them with FreeColors, and it works fine when the colormap has a read/write
kind of visual (GrayScale, PseudoColor, DirectColor).  When the visual
is a static one (StaticGray, StaticColor, TrueColor), any attempt to
FreeColors gets an Access error.  Philosophically, it doesn't make a lot
of sense to "reserve" and "free" color cells in an immutable color map, but
the protocol is documented to allow it (and it makes the client code simpler).

Is this a common mistake in X server implementations?  I've noticed this
behavior with MIT X11R4 (p/l 14) on a DECstation, the Ultrix 4.0 product
server, and a Visual X terminal.  Visual said it was a bug in the server
and is corrected the latest release.

      -- Larry