"Timed out waiting for property-notify event" on RealVNC 4.X

[Andrew M. Scott]

PROBLEM:

Emacs "Timed out waiting for property-notify event" on RealVNC 4.X
vncconfig when a large (> 2.5MB) portion of text is kill-ring-save(d).

Unfortunately, the EDA tool ascii log files we deal with are regularly
larger than 2.5MB.

Our use model is to run VNC viewer on one OS (e.g. WindowsXP Pro) and
run the EDA tools, Emacs, vncserver and vnconfig binaries on gnu/linux
platforms. 

I had not problem editing the same testcase in one vim-6.3 editor
session and copying the file contents and pasting into another vim-6.3
invocation, in the same VNC session.

DETAILS:

My personal experience is "large" seems to be (ascii) files > 2.5MB
using vncconfig 4.1.1 or vncconfig Enterprise 4.1.7 and either
(setq x-select-enable-clipboard t) or 
(setq x-select-enable-clipboard nil) <= the default

I am using the fvwm v2.4.19 window manager not KDE. vncserver
and vncconfig were run on a gnu/linux server, and vncviewer is
running on a WindowsXP Pro laptop.

I've seen this same behavior on Emacs-21.3 through the current
CVS Emacs-22.X

These symptoms appear to be similar to the Emacs etc/PROBLEMS entry:

 * Emacs hangs on KDE when a large portion of text is killed.
 This is caused by a bug in the KDE applet `klipper' which periodically
 requests the X clipboard contents from applications.  Early versions
 of klipper don't implement the ICCM protocol for large selections,
 which leads to Emacs being flooded with selection requests.  After a
 while, Emacs will print a message:

     Timed out waiting for property-notify event

     A workaround is to not use `klipper'.

HOW TO REPRODUCE (Using CVS Emacs-22 build from April 27 snapshot):

Start VNC server and vncconfig helper app
% vncserver
% vncconfig -poll=3000 -nowin  &

In an xterm in the new vncsession:

Concatenate 5 copies of etc/NEWS together
% cat NEWS NEWS NEWS NEWS NEWS > 5NEWS
% emacs -Q &

C-x C-f 5NEWS  <i.e. visit file>
C-x h          <i.e. mark-whole-buffer>
M-w            <i.e. kill-ring-save>

Minibuffer immediately echoes:
Saved text until "g:1aca9dfa-2ac4-4d14-bebf-0007cee12793
"
but emacs becomes unresponsive. Eventually, I get an additional
minibuffer message "Timed out waiting for property notify event." 

After this point Emacs is unresponsive or erratic. Sometimes I can hit
several C-g's and it'll allow another 1-5 C-n's, then I'll have to hit
several C-g's again to get it to move a few more C-n's. It doesn't
respond to C-p in either case.

I just tried it again under gdb.
% gdb /stor/garray/linux_2.6.5_x86-64/bin/emacs
GNU gdb 6.3
...
(gdb) run -Q
M-: (setq debug-on-quit t)
C-x C-f 5NEWS  <i.e. visit file>
C-x h          <i.e. mark-whole-buffer>
M-w            <i.e. kill-ring-save>

Minibuffer immediately echoes:
Saved text until "g:1aca9dfa-2ac4-4d14-bebf-0007cee12793
"
This time, after getting the "Timed out waiting for property notify
event." message, I hit C-g, and asked for a backtrace

Program received signal SIGABRT, Aborted.
0x0000002a969cf6f9 in kill () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x0000002a969cf6f9 in kill () from /lib64/tls/libc.so.6
#1  0x00000000004a6045 in abort ()
#2  0x000000000050f888 in internal_condition_case ()
#3  0x00000000004a8a6a in command_loop_2 ()
#4  0x000000000050f4b0 in internal_catch ()
#5  0x00000000004a8816 in command_loop ()
#6  0x00000000004a8901 in recursive_edit_1 ()
#7  0x00000000004a8a39 in Frecursive_edit ()
#8  0x0000000000511a72 in Ffuncall ()
#9  0x000000000053d12c in Fbyte_code ()
#10 0x0000000000510e50 in Feval ()
#11 0x000000000051114f in Fprogn ()
#12 0x000000000044c894 in Fsave_window_excursion ()
#13 0x000000000053d57c in Fbyte_code ()
#14 0x00000000005112aa in funcall_lambda ()
#15 0x000000000051183e in Ffuncall ()
#16 0x0000000000512eb5 in Fapply ()
#17 0x0000000000512fcd in apply1 ()
#18 0x00000000005104c7 in call_debugger ()
#19 0x0000000000510828 in find_handler_clause ()
#20 0x0000000000511e0f in Fsignal ()
#21 0x0000000000545aef in wait_reading_process_output ()
#22 0x0000000000493054 in wait_for_property_change ()
#23 0x00000000004937de in x_handle_selection_event ()
#24 0x00000000004b0448 in swallow_events ()
#25 0x0000000000545c25 in wait_reading_process_output ()
#26 0x0000000000413999 in sit_for ()
#27 0x00000000004b2659 in read_char ()
#28 0x00000000004b4622 in read_key_sequence ()
#29 0x00000000004b6212 in command_loop_1 ()
#30 0x000000000050f84e in internal_condition_case ()
#31 0x00000000004a8a6a in command_loop_2 ()
#32 0x000000000050f4b0 in internal_catch ()
#33 0x00000000004a8868 in command_loop ()
#34 0x00000000004a8901 in recursive_edit_1 ()
#35 0x00000000004a8a39 in Frecursive_edit ()
#36 0x00000000004a7b61 in main ()

WORKAROUNDS/REMEDIES:

1. Is there a way that GNU Emacs can be made more "tolerant" of the 
   "Emacs being flooded with selection requests" issue mentioned in
   etc/PROBLEMS for klipper? (I'm assuming at this point that the
   this is the problem is the same for vncconfig).

   I'm a gdb, C, and X11 programming novice. I'll need explicit
   instructions if there is any debugging assistance I can provide to
   narrow the problem.

2. Killing vncconfig 4.X isn't really a solution to my general need
   for cut/paste support between apps within/between VNC sessions,
   clients and/or Microsoft Windows apps.

In GNU Emacs 22.0.50.1 (x86_64-unknown-linux-gnu, X toolkit)

Andy Scott