sysmark@physics.utoronto.ca (Mark Bartelt) (03/08/91)
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. In fact, I find myself stymied by a problem which neither the SGI man pages for X (at least, the ones I've looked at; there are *lots* of them aren't there? :-) nor the various X books at my disposal explain, at least at a level which a neophyte like me can understand. First, the background: I've taken on the somewhat unenviable task of porting a moderately large (~35mb of source code) software package to the IRIS. This software runs on a variety of hardware configurations, and drives a variety of graphics devices. The "correct" thing to do is to write a GL version of the package's graphics routines, but since this software now comes with X support, it seemed reasonable to start off using the distributed X stuff, in order to get something up and running soon, while the GL-based stuff got written. The way its X support works is that a server program creates a window using Xlib calls. It accepts a socket connection from the application process, which sends commands to the server, telling the server to do things to the window. Seems like it ought to port trivially, right? After all, isn't that the whole point of X, easy portability and such? (1/2 :-) 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) Minor opcode of failed request: 0 Resource id in failed request: 0x0 Serial number of failed request: 53 Current serial number in output stream: 54 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 call to XPending happens every time through the main loop, which, besides invoking Xpending, also checks the socket which it uses to communicate with the client). I could provide the sequence of Xlib calls that the server makes before the XPending bombout, but I doubt that it's terribly relevant to understanding this problem. (Correct me if I'm wrong!) Being a total X neophyte, I'm not even sure which man pages to start reading. And I have no idea whether the failure above is connected with the fact that XAllocColorCells fails at initialization time. I presume that there is. 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). I've RedTFM, but haven't yet stumbled across anything that addresses this issue. Can anybody who really understands this X stuff explain what's going on? Or suggest where the problem might lie? Or point me to a good reference? Note that this server (allegedly) works just fine under other vendors' versions of X, though I haven't actually tested that yet. So I suspect something odd with SGI's implementation, but don't know how to discover what's different, nor how to work around it. To ask the time-honoured question, is this a bug or a feature? As usual, thanks in advance. -- Mark Bartelt 416/978-5619 Canadian Institute for sysmark@cita.toronto.edu Theoretical Astrophysics sysmark@cita.utoronto.ca
mikey@eukanuba.wpd.sgi.com (Mike Yang) (03/08/91)
In article <1991Mar7.201724.22547@helios.physics.utoronto.ca>, sysmark@physics.utoronto.ca (Mark Bartelt) writes: |> 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: I'm going to assume that you're running IRIX 3.3. Under 3.3, the default invokation of the X server provides a visual whose colormap contains only 16 read/write colormap cells. The remainder are read-only. This situation allows GL and X programs to co-exist without colormap conflicts. However, if you try and run an X program which requires more colormap cells, or expects to be able to modify large numbers of them (as your application seems to), you're going to run into problems. One possible solution is to start your X server such that most of the colormap cells are read/write. If you create a ~/.xSGINeWS.cmd with: /usr/bin/X11/Xsgi -bs -gl all but 16 of the colormap cells will be read/write the next time you login. Be aware, however, that if you do this your GL programs may display with the "wrong" colors. Furthermore, from your description of your problem, your application seems to be using XStoreColors without taking into account the value returned by XAllocColorCells. If your program expects all the colormap cells to be read/write, you may still get your X error. Although this may often be the case with other vendor's X servers, it's not with ours. By the way, the reason why your application emits the error in XPending is because the X protocol is asynchronous. Until that call, your requests are queued up and haven't been processed. The best way to pinpoint the location of an error is to use -sync with Xt programs, or use XSynchronize to cause requests (e.g. XStoreColors) to occur at the time the Xlib function is called. ----------------------------------------------------------------------- Mike Yang Silicon Graphics, Inc. mikey@sgi.com 415/335-1786
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/09/91)
> 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