P E Jareth Hein writes: P> Well, I'm not sure what causes them, and I put that there originally to P> help me find out more about them. They won't cause crashes, but they are P> most likely indicative of mishandled colors (or possibly mis-read X P> specs... <grin>). I've never seen one in the 5 or six different platforms I P> work on, and would like to know why they happen, so I can fix whatever P> wierdness is there. But, they probably should go away for a non-beta P> release... Jareth, here are some clarifications you might find usefull: If I understood well the scheme you use in allocate_nearest_color, when you notice that the colormap is full, you scan it to find the closest one already available in the colormap, and try to allocate this one, right ? Well, this can fail (and thus generate the messages that Steve got) for to reasons that I can think of (I assume that we're talking about user-modifiable colormaps, e.g. PseudoColor): 1/ First, between the time you find the closest color and the time you try to allocate it, the colormap may have changed. For example, the reference count on that particular color cell went back to 0, and somebody else than you allocated it back with something else. No more closest color in the colormap. 2/ Second, the colormap doesn't change, but the candidate you found is allocated read/write by another client. I think that's what happens to Steve, since Netscape seems to perform a massive XAllocColorCells at startup. Then XAllocColor fails because it's supposed to return a read-only cell, and the one you found could be changed any time by its owner. As the second case is much more likely to happen than the first one, a solution would be to sort the colormap by closeness order, and try all candidates until one succeeds. Being aware, however, that this solution could still fail in very rare and weird cases[1]. But anyway, I think you shouldn't use fprintf, but maybe a standard error signaling routine. <pendantic PS> Ah, anda... you function doesn't follow the GNU coding standards very much ;-) </pendantic PS> Footnotes: [1] in such cases, you could also restart the whole algorithm. I mean rescanning the whole colormap and so on. Theoretically, what we'got here is a beautiful potential infinite loop :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19