I also sent a description of this problem to the xemacs community.  "Stephen J. 
Turnbull" <stephen@xemacs.org> replied with a message that included the 
following information.

  It's possible that it's an XEmacs bug, but the last time I tried to
  debug this I put a trace on the window creation function and those are
  definitely not XEmacs's windows.  We may have misimplemented the
  protocol (see below), but the folks who did that work were pretty
  wizardly.

  Caveat: I don't understand the following, I'm just repeating what
  somebody else diagnosed.

  Apparently some applications misuse the X selection, by setting the
  owner to a window that they later destroy without disowning the
  selection.  The X selection (or maybe it's the clipboard) protocol
  requires some communication with the former owner when this is done,
  but that window no longer exists so you get the bad resource message.
  GNOME applications are apparently especially prone to this behavior.

Can someone suggest how I might start trace nautilus' window creation and 
destuction activity?

g.

Doesn't seems to be something due to nautilus at all

I can reproduce something very similar on nautilus 2.22.

Run xemacs on a file and cut some text.
xemacs hangs with stack trace

bash-3.2$ pstack 2672
2672:   xemacs starthere.desktop
 fe84cd47 pollsys  (8536300, 1, 0, 0)
 fe7fed32 poll     (8536300, 1, ffffffff) + 52
 feb026ba _XWaitForReadable (854e000) + de
 feb024e6 _XRead   (854e000, 80472a0, 20) + 1b6
 feb03251 _XReply  (854e000, 80472a0, 0, 1) + cd
 feb0ee4a XInternAtom (854e000, 80472f0, 0, 52414843, 45544341, 4f505f52) + 8a
 081b1d0e ???????? (8535300, 847393c, 0)
 081b3728 ???????? (8535300, 8662980, 8047430, 8047434, 8047438)
 081b285c x_handle_selection_request (1e5a, 829a400, 851f904, 851f844, 851f8e4, 84db6a0) + 19c
 08536400 ???????? (1ba08, 0, 0, 0, 0, 0)
 52dfcc00 ???????? ()

after outputting


xemacs: X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  25 (X_SendEvent)
  Resource id in failed request:  0x18001de
  Serial number of failed request:  1991
  Current serial number in output stream:  1992
Xlib: unexpected async reply (sequence 0x7c8)!

xemacs: X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x18001de
  Serial number of failed request:  1990
  Current serial number in output stream:  1992


The resaon that we think that it has something to do with nautilus is that the problem does not occur if nautilus is not running.

I am transferring this to gtk as it seems that the code fragment

  if (widget != get_clipboard_widget (gtk_widget_get_display (widget)))
    gtk_widget_destroy (widget);

in selection_changed in gtkclipboard.c seems to be the cause of the problem.
If this code is omitted then the problem does not occur. 

The code fragment is in selection_received in gtkclipboard.c.

The Resource id in the bad Windows errors correspond to the X Window of the GdkWindow of the widget being destroyed by the call to gtk_widget_destroy in selection_received in gtkclipboard.c.

I have also logged http://tracker.xemacs.org/XEmacs/its/issue389

My evaluation results shows the following:
1.When select contents from xemacs window, three owner-changed signal emitted to the clipboard owned by Nautilus ( kinda weird as generally only one emitted).
2. in gtk_clipboard_request_contents, the contents info was set to the widget when the first signal emitted, thus, two new widgets are created with follwoing code section:

  clipboard_widget = get_clipboard_widget (clipboard->display);

  if (get_request_contents_info (clipboard_widget))
    widget = make_clipboard_widget (clipboard->display, FALSE);
  else
    widget = clipboard_widget;
3. Three selection_received signal received by the clipboard, each widget has one, as mentioned by Patraig, two widget has been destroyed as it failed with get_clipboard_widget . 

I believed later xemacs window want to access these two destroyed windows, and then meet badwindow error.

The root cause of the bug is why multiple owner changed signal generated. It may require further evaluation by both xemacs community and gnome community. I don't have a good idea on how to work around this yet, to remove the widget_destroy is not a good idea, as we will have two widget created each time copy-paste, It may less harmful if we don't create new widget if the widget contents_info has been set. 

Just my two cents.

Just tried this on latest Gnome 2.25 and I cannot recreate the issue, so maybe this has been fixed indirectly by something else :)

Can someone else verify this.

I can still met this issue with XEmacs 21.1 on GNOME 2.28 when I cut&paste.

xemacs: X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Resource id in failed request:  0x14002f0
  Serial number of failed request:  7366
  Current serial number in output stream:  7367

xemacs: X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  25 (X_SendEvent)
  Resource id in failed request:  0x14002f0
  Serial number of failed request:  7367
  Current serial number in output stream:  7367

I got XEmacs from http://ftp.xemacs.org/pub/xemacs/binaries/solaris/

This may have been fixed by commit 430ea2fff639f31b868e025002a32ba473c7bd07