mouse@LARRY.MCRCIM.MCGILL.EDU (09/14/90)
I'm having a bit of trouble with allocating colors from immutable colormaps (ie, colormaps corresponding to a visual type of StaticGray, StaticColor, or TrueColor, though I have never tried this with a TrueColor visual (I have with StaticColor and StaticGray visuals)). The problem is that XFreeColors barfs on my attempt to free a cell in the screen's default colormap that I allocated with XAllocColor. (The error is BadAccess.) The first time this happened, I was inclined to write it off as a buggy server (it was with a vendor-supplied binary-only server). The second time, though, the server was the MIT sample server.... This does not happen on 1-bit displays that use mfb. However, on deeper displays using cfb, it is repeatable. Looking at the server code reveals that it happens whenever XFreeColors is called to free a cell in a colormap created with AllocAll. Further investigation reveals that when mfb is called upon to create a default colormap, it uses AllocNone, but if the root's visual is an immutable visual, cfb uses AllocAll. So the error is just what one would expect. What's wrong here? My inclination would be to make cfb use AllocNone all the time, but I don't feel I understand all the ramifications of doing so. Clearly, mfb works when using AllocNone, but then, mfb explicitly allocates all the cells of its colormap with AllocColor(). I suppose there is no need to free cells allocated out of an immutable colormap, but there is no obvious reason to make clients check the visual type before freeing cells allocated with XAllocColor(). The Xlib manual is not as explicit as I would like, but I *think* it indicates that my expectations are correct - XFreeColors() should free cells allocated with XAllocColor(), even if the colormap is immutable. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/14/90)
What's wrong here? A bug in the server, clearly. Please submit a bug report. Thanks.