Re: Problem copying large text under X

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

>     Sometimes this takes a long time and emacs seems to hang...
>
> We might need an X wizard's help to debug this.
>
>     #13 0x402204fd in _XReply () from /usr/X11R6/lib/libX11.so.6
>     #14 0x4021b975 in XSync () from /usr/X11R6/lib/libX11.so.6
>     #15 0x080e4fd6 in x_catch_errors_unwind (old_val=137755221) at 
> xterm.c:7622
>
> What happens if you put BLOCK_INPUT around that call to XSync?  Does
> that prevent it from crashing here?
>

C-g doesn't signal the x-error anymore, which is good.

And emacs does become responsive again ... but it's somewhat
slow to react to e.g. moving point.

Here's a new backtrace which indicates that it's still waiting for the
clibboard action to complete...

#0  0xffffe002 in ?? ()
#1  0x080f59aa in wait_for_property_change (location=0x85581c0) at 
xselect.c:1120
#2  0x080f4f87 in x_reply_selection_request (event=0xbfffcff0, format=8, 
data=0x88b8424 "eturn success_p;\n}\n\n\f\n/* Get information about the 
tool-bar item at position X/Y on frame F.\n   Return in *GLYPH a pointer to the 
glyph of the tool-bar item in\n   the current matrix of the tool-bar wi"..., 
size=670817, type=234) at xselect.c:724
#3  0x080f5211 in x_handle_selection_request (event=0xbfffcff0) at xselect.c:841
#4  0x0811302f in swallow_events (do_display=1) at keyboard.c:4215
#5  0x081c73cc in wait_reading_process_output (time_limit=97, microsecs=0, 
read_kbd=-1, do_display=1, wait_for_cell=137730969, wait_proc=0x0, 
just_wait_proc=0) at process.c:4466
#6  0x0805ace0 in sit_for (sec=97, usec=0, reading=1, display=1, 
initial_display=0) at dispnew.c:6365
#7  0x08110a41 in read_char (commandflag=1, nmaps=2, maps=0xbfffd5a0, 
prev_event=137730969, used_mouse_menu=0xbfffd68c) at keyboard.c:2758
#8  0x08119c66 in read_key_sequence (keybuf=0xbfffd800, bufsize=30, 
prompt=137730969, dont_downcase_last=0, can_return_switch_frame=1, 
fix_current_buffer=1) at keyboard.c:8830
#9  0x0810da6a in command_loop_1 () at keyboard.c:1528
#10 0x0818787f in internal_condition_case (bfun=0x810d64d <command_loop_1>, 
handlers=137791945, hfun=0x810d165 <cmd_error>) at eval.c:1367
#11 0x0810d4aa in command_loop_2 () at keyboard.c:1309
#12 0x08187329 in internal_catch (tag=137785953, func=0x810d48b 
<command_loop_2>, arg=137730969) at eval.c:1128
#13 0x0810d45d in command_loop () at keyboard.c:1288
#14 0x0810cedb in recursive_edit_1 () at keyboard.c:981
#15 0x0810d01c in Frecursive_edit () at keyboard.c:1042
#16 0x0810b906 in main (argc=2, argv=0xbfffde14) at emacs.c:1738
#17 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6


After a (long) while, it does seem to terminate the clipboard protocol
and things are back to normal performance.

It could seem like the clipboard program (KDE klipper) is slow,
but it does seem to get the whole data eventually.

I'll investigate further.

-- 
Kim F. Storm  http://www.cua.dk