Re: [Bug: 21.4.12] Deadlock with X?

Greg Badros wrote: Note: the backtrace which Stephen queried *does* have _XRead() in it. Also, *all* of the backtraces have a NULL device argument, which is just too improbably (it not only shouldn't be able happen, but if it did, XEmacs should segfault almost instantly, before it gets down into Xlib). I don't think so. The odd one out (the second one) appears to differ from the other two only in that there aren't any symbols for the Xlib portion. Most of the addresses match. The thing is, everything points towards problems at a lower level than XEmacs itself, i.e. in the communication between Xlib and the X server (X Errors mentioning obviously bogus resource IDs, Xlib's "unexpected async reply" message, crashes in XRead()). Assuming that neither the X server nor Xlib are outright broken, the next most likely explanations include Xlib not being compatible with other key components (e.g. libc, or the Xlib headers), or something dumping garbage into the socket. This is just a complete shot in the dark, but can you check the output from "ls -l /proc/<pid>/fd", where <pid> is the PID of the XEmacs process. I'm curious as to whether the X socket is getting assigned to one of the standard descriptors (0, 1 or 2). -- Glynn Clements <glynn.clements(a)virgin.net&gt;