Probably something to do with the new async code in GDK,
but without getting the errors myself, I can't debug it.

I donwgraded just the XFree86 server and everything seems to work with
out problems, i guess it is an XFree86 bug.

i just compiled gnumeric from cvs and when trying to make a plot
gnumeric quits and shows this output on the terminal:

Xlib: sequence lost (0x10000 > 0x86b7) in reply type 0x0!
Xlib: sequence lost (0x10001 > 0x86eb) in reply type 0x1f!
Xlib: sequence lost (0x10000 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10002 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10000 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10300 > 0x86ec) in reply type 0x2!
Xlib: sequence lost (0x10202 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10100 > 0x86ec) in reply type 0x2!
Xlib: sequence lost (0x10000 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10100 > 0x86ec) in reply type 0x0!
Xlib: sequence lost (0x10000 > 0x86ec) in reply type 0x2!
 
(gnumeric:9416): Gdk-WARNING **: gdkproperty-x11.c:299 invalid X atom:
100663296Xlib: sequence lost (0x10500 > 0x86ed) in reply type 0x0!
Xlib: sequence lost (0x10400 > 0x86ed) in reply type 0x1!
 
(gnumeric:9416): Gdk-WARNING **: gdkproperty-x11.c:299 invalid X atom:
797357824Xlib: sequence lost (0x10300 > 0x86ed) in reply type 0x0!
The program 'gnumeric' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 768 error_code 2 request_code 0 minor_code 247)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error()
function.)

if i run gnumeric --sync everything works smoothly.

note: i have the same versions of GTK+ and XFree86 that i had when i
got your answer on 2003-08-01, this may indicate that gtk+ might
actually have a bug in the new async code.

If you need more data i would be very pleased to provide it, just tell
me what you need and what i would have to do, i have never debugged a
bug where deep X knowledge was required.

Well, the first thing to do is to find the simplest program
you can that exhibits misbehavior. Start with the test
programs that come with GTK+.

Trying to debug problems with gnumeric or nautilus is 
vastly harder.

i have been able to get the same behaviour with the demos in gtk-demo,
*but* it is not reproducible, i can't get it to fail at the same
point, every time i have to do diferent things.

The things that i have done basically consist on clicking a lot on the
windows and buttons and changing the active window back and forth.
With this simple things most of the demos fail somewhere.

i know that it is not a lot of information nor it is very useful but
it is what i got.

I am using X version 4.3.99.10 cvs glib/atk/pango/gtk+ from the date
of this post,
and testgtk from the tests/ subdirectory.

Like the other reporter, when I run with --sync, I get no errors.

I have found that I can reproduce crashes by simply entering and leaving
the very bottom I can get it to crash.

From what I have been able to tell, I must at least focus the 'Close'
button to get it to crash. If I initally unfocus, and then enter ,
focus the 'close', leave, it will crash in 2 to 3 tries. When it
crashes, it crashes as I touch the button, but after it has been
highlighted blue.

The error that I get, however, is '124'

ok, here we go, a way to reproducte it:

1) launch an xterm
2) from the xterm launch gtk-demo, gtk-demo windows gets focus, switch
focus by clicking on xterm and then on gtk-demo again
3) repeat 2, eventually gtk-demo will die with this message:
diego@helios:~$ gtk-demo 
Xlib: sequence lost (0x10806 > 0x2baa) in reply type 0xa0!
Xlib: sequence lost (0x10000 > 0x2baa) in reply type 0x0!
The program 'gtk-demo' received an X Window System error.
This probably reflects a bug in the program.
The error was '32'.
  (Details: serial 1281 error_code 32 request_code 180 minor_code 170)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error()
function.)
diego@helios:~$ 

rigth after this happends if i click on the desktop nautilus dies
inmedialety with this message:

The program 'nautilus' received an X Window System error. 
This probably reflects a bug in the program.   
The error was '240'.
  (Details: serial 49151 error_code 240 request_code 0 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error()
function.)

i just updated glib (the last entry of the gobject Changelog is: 

Tue Aug 19 01:31:28 2003  Tim Janik  <timj@gtk.org>

        * gsignal.c: added optimizations to skip NOP signal emissions.

i have not updated GTK, i still have the same version

hope this helps some

an easier and faster way to reproduce it:

1) launch xterm
2) launch gtk-demo from xterm

inmedialety after the window appers click on the xterm window, now
click on the gtk-demo windows

it dies in the act, no need to do anything else

Xlib: sequence lost (0x1080b > 0x719) in reply type 0x98!
Xlib: sequence lost (0x10000 > 0x719) in reply type 0x1!
Xlib: unexpected async reply (sequence 0x0)!
Xlib: sequence lost (0x10808 > 0x719) in reply type 0x0!
The program 'gtk-demo' received an X Window System error.
This probably reflects a bug in the program.
The error was '162'.
  (Details: serial 2056 error_code 162 request_code 0 minor_code 2)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error()
function.)

if you click on the gtk-demo window first it will take longer to die,
but it eventually will die after changing the focus several times with
the mouse.

I would like to confirm this behaviour. This is happening for quite
some months now (also the reason why I switched to gtk+-2-2 branch
again). But now I liked to play with the new widgets in GTK+ HEAD and
thus compiled my entire GNOME with that version of GTK+ and the
problem still persist. E.g. clicking on Titlebar or Firebird == Crash,
clicking on NotificationArea == Crash of Panel + Crash of Nautilus in
one go and stuff like that.

GNOME work's more or less normally if you DO NOT touch it :). Anyways
I'm no xlib guru thus I can not help determine whether this is a XFree
CVS problem or a GTK+ problem but since this doesn't happen with
gtk+-2-2 branch...

A minority of stability would be cool. So we can 'more or less'
operate normally.

Keith Packard believes he's fixed problems introduced
into Xlib into XFree86 CVS version since 4.3 shipped.  There were
threading bugs introduced, and out and out crashers (god forbid
you use CMS).

Please try out the Xlib version found in the freedesktop.org
CVS and see.

I'll be looking over other patches to Xlib since 4.3, since it is
clearly not getting tested well.
                         - Jim Gettys

i just compiled both, everything seems to work as expected now, thanks
a lot

Diego