i see this too, sometimes. in particular, if i compile cygwin with pdump, and cd to src, and grep foo *.c, often times i see the same problem and xemacs locks up. however, before i checked my code in i verified that this problem already existed -- i.e. my changes didn't cause the problem. i have no idea what did cause it, though ... i don't understand what would cause a lost sequence. i don't understand how processes could have anything to do with x lib problems. btw the place where it locks up for me is always in XAllocColors, and during normal running i also get various X errors from XQueryColor, from x_frame_property. could this have anything to do with it? it would be useful if someone on a Unix system could try reconstructing some of the earlier 21.5 betas and seeing if you can figure out which beta the problem started in. there have been lots of random changes by lots of people that could possibly be triggering the problem ... the useful thing about the nil is it tells us that child_setup() is not involved in causing the problem -- it must be something before. ----- Original Message ----- From: "Michael Sperber [Mr. Preprocessor]" <sperber(a)informatik.uni-tuebingen.de&gt; To: <xemacs-beta(a)xemacs.org>; "Ben Wing" <ben(a)xemacs.org&gt; Sent: Friday, May 31, 2002 2:17 AM Subject: Reliable way to lose X sequence

About XQueryColor, see also: http://list-archive.xemacs.org/xemacs-beta/200202/msg00309.html I have pinged Bill Perry several times about this because I believe this problem first occurred when he checked in the generic toolbar code. sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: - vin -- In a minute there is time For decisions and revisions which a minute will reverse. T.S. Eliot [URL: http://www.cs.amherst.edu/~ccm/prufrock.html]

"Ben Wing" <ben(a)666.com&gt; writes: I didn't remove the x specific toolbar chunks from device/console structures, just to minimize my patch. Does this patch work for everyone? It seems to fix the problem here. I couldn't repro for a while because KDE was sneaking in some X resources, so my toolbar stuff was always initialized.:( Sorry for the long delay - lots of vacation and work mixed in lately. -bp -- Ceterum censeo vi esse delendam

William M. Perry writes: If thine eye offends thee, pluck it out... ? Are the toolbar colors going to work without this code?

William M. Perry writes: It seems not to be working. I use this X resource. xemacs*backgroundToolBarColor: rgb:de/b8/87 It's being picked up in 21.4.8. It's not being picked up in 21.5.

Kyle Jones <kyle_jones(a)wonderworks.com&gt; writes: I don't think thats the right way to go. Maybe some mucking in x-faces.el to pick up the old resources if the toolbar face hasn't been modified? Removing the duplicated code is a good thing, and using faces instead of resources is a good thing as well. :( -bp -- Ceterum censeo vi esse delendam

Ben> it would be useful if someone on a Unix system could try reconstructing some of Ben> the earlier 21.5 betas and seeing if you can figure out which beta the problem Ben> started in. I just saw that I screwed up: the problem is also visible in 21.4.4, but not in 21.1.3 :-) -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

OK, I think I understand to some extent what's going on here -- at the very least, I can certainly see what goes wrong with the nil for argument. It doesn't explain my periodic M-x grep problems with pdump, though. Basically, the key problem is that the error is getting signalled INSIDE THE CHILD. That's bad. Even though we don't use vfork(), so the two are separate processes, they still share some handles, in particular the X connection. So when the error occurs, the child will proceed on its way, signalling the error and ultimately trying to display on the screen. At this point, you have two processes talking to the same X connection, so of course the parent Xlib gets confused. i assume all such problems ultimately have to boil down to I/O on the socket by the child. This could conceivably come from QUIT checking, for example -- if something in the child process setup code invokes QUIT, and there's some I/O pending on the socket, it will do I/O trying to figure out if C-g was pressed. Another possibility: somewhere along the way someone added the following to the end of child_setup(): /* I can't think of any reason why child processes need any more than the standard 3 file descriptors. It would be cleaner to close just the ones that need to be, but the following brute force approach is certainly effective, and not too slow. */ { int fd; for (fd = 3; fd <= 64; fd++) retry_close (fd); } Besides the fact that the check for <= 64 is obviously wrong and should be < 64, there is already code earlier on to close all the open descriptors that XEmacs owns -- i.e. all processes and files currently being loaded. i don't understand Unix very well -- could closing a socket (e.g. the X socket) possibly cause some flushing of the buffers, even if there's another handle onto the same descriptor in the parent process? my bet has to do with QUIT checking. in particular any call that does DFC-type text conversion -- e.g.qxe_open(), qxe_chdir(), etc. etc. -- can trigger a QUIT check. It will be likely if e.g. you move the mouse after starting the process or maybe there's a key release waiting to be processed. the reason why this may have started appearing more often in 21.5 -- even though you can still get the problem using the `nil' trick in 21.4 -- is that the filename translation was added in 21.5. the solution is to wrap the entirety of the child process in begin_dont_check_for_quit(). you don't need to bother ending this because once we execvpe(), everything's wiped out anyway. Michael, can you try this and see if it fixes your problems (other than the nil problem, which needs a different fix)? ben ----- Original Message ----- From: "Michael Sperber [Mr. Preprocessor]" <sperber(a)informatik.uni-tuebingen.de&gt; To: <xemacs-beta(a)xemacs.org>; "Ben Wing" <ben(a)xemacs.org&gt; Sent: Friday, May 31, 2002 2:17 AM Subject: Reliable way to lose X sequence