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>
To: <xemacs-beta(a)xemacs.org>; "Ben Wing" <ben(a)xemacs.org>
Sent: Friday, May 31, 2002 2:17 AM
Subject: Reliable way to lose X sequence
In the latest beta, do:
(start-process "foo" (get-buffer "*scratch*") "ls" nil)
This gets you:
Xlib: sequence lost (0x10000 > 0x3e5) in reply type 0x1!
... and XEmacs becomes unusable. I don't see this in 21.4.4.
Now, I and others have been seeing process-related sequence-lost
problems for *a long* time, so maybe this is related. (I know the nil
is invalid---XEmacs still shouldn't crash.)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla