bzs@BU-CS.BU.EDU (Barry Shein) (06/04/87)
Version: V10R4 System: Sun3/3.0 When I resize a window created by XCreateTerm() to be largish (not the whole screen, maybe 2/3) using the uwm resize menu choice the whole thing will repeatedly hang, no mouse tracking etc. Updating the window involves drawing many small windows (around 200.) The windows get mostly drawn when it hangs. I get on another terminal and kill -QUIT (just before the core dump the window update finishes as I expected, like the buffers finally get flushed.) Inspecting the core file it seems to be in write() called from _XFlush() called from XNextEvent(). Anyone know what's causing this? I'm looking but it all seems ok, the only thing that comes to mind is that the buffer is full and we've entered some sort of deadlock with the server, but that's just a wild guess. I'll keep looking, just hoping someone knows the fix or where to look. On another note, trying to do the typical XLine() using GXxor to track a line (eg. a crosshair) in a window doesn't work. It seems to simply do a GXcopy and the screen just fills with black lines. Is it me? -Barry Shein, Boston University
garfinke@hplabsc.UUCP (06/04/87)
# Subject: Applications Hanging? Does XLine work? > I get on another terminal and kill -QUIT (just before the core dump > the window update finishes as I expected, like the buffers finally get > flushed.) Inspecting the core file it seems to be in write() called > from _XFlush() called from XNextEvent(). > Anyone know what's causing this? I'm looking but it all seems ok, the > only thing that comes to mind is that the buffer is full and we've > entered some sort of deadlock with the server, but that's just a wild > guess. I've seen this happen before and the cause is that the client is writing to the server and blocks when the socket is full. At the same time, the server is sending packets back to the client (in this case maybe an expose event) and the since the client is not consuming these events, the server blocks when the socket is full. Poof, deadlock. When the process is killed, X wakes up from the write and processes the remaining requests. The key here is not to keep on doing operetions which cause events to be generated without consuming them. Maybe setting a timer before doing an XFlush will help. I suppose it is the server responsibility to not hang the system, but since thats not how they're written, you'll have to put some type of workaround in your client. Dan Garfinkel, HP Labs
jg@jumbo.dec.com (Jim Gettys) (06/05/87)
This is a generic problem in the V10 X library; the library really should read events if it is blocked on write. This would avoid the deadlock. The V11 X library is written in this way; whenever it can't send more data it will in the meanwhile enqueue events. - Jim