I have been seeing an issue for a while, where screen appears to be
going into a busy loop when pasting data into vim.  Not exactly sure how
to reproduce this, but something along these lines seem to always work
when the data is important (but I cannot reproduce it consistently):

1. for((i=1; i<1000; i++); echo $i; done
2. ctrl-a [
3. ? for
4. space
5. G
6. space
7. ctrl-a c
8. vim
9. i
10. ctrl-a ]
11. observe 100% cpu utilization of the screen process

I tried to grab a strace but I am getting:

attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

When it works, it takes ~3 sec paste the 10k lines on my box, and when
you hit the issue I never seen it terminate.  I am not convinced that it
stricly an issue with how much data you are pasting, but I have a
feeling it depends either on how much data you have in your scrollback
buffer (my defscrollback is set to 10k) or perhaps how far back you went
to copy the chunk of data.

It may be an issue with vim, as I have never been able to reproduce it
pasting into other programs (then again, I do not think that I usually
paste into anything else).

Control: found -1 4.6.2-3+deb10u1
Control: found -1 4.8.0-6

 > Package: screen
 > Version: 4.0.2-3
 > Severity: normal

 > I have been seeing an issue for a while, where screen appears to be
 > going into a busy loop when pasting data into vim.  Not exactly sure
 > how to reproduce this, but something along these lines seem to always
 > work when the data is important (but I cannot reproduce it consistently):

[…]

 > When it works, it takes ~3 sec paste the 10k lines on my box, and when
 > you hit the issue I never seen it terminate.

	I was able to reproduce it with both 4.6.2-3+deb10u1 and 4.8.0-6;
	it seems, however, that an important part is to signal Screen
	while it sends the data down to the application; such as with:

	1. $ seq 1 0x100000 | fmt -w78 > /tmp/screen-exchange .

	2. $ screen ; then load the file with C-a < .

	3. $ vim.tiny ; start pasting the data there with C-a ] .

	4. Press ^C while Screen is still sending the data.

	5. Screen appears to enter an infinite loop: 100% CPU
	   utilization, no syscalls seen via strace(1), etc.

	Given that this bug effectively results in the loss of a given
	Screen session, possibly with all the (‘unsaved’) data therein,
	I believe it deserves a higher Severity: .

	(Could #524304 be possibly related?)

	As a workaround, some applications may be salvaged with
	reptyr(1); like:

	1. Find out the PID of the ‘broken’ session:

$ pgrep --full -u"$(id -u)" -- ^SCREEN\\b
1234
$

	   (It’s possible to $ kill -STOP the process here so that it no
	    longer consumes CPU cycles.)

	2. Find out the PIDs of the programs running under:

$ pstree -Apl -- 1234
screen(1234)-+-vim(2468)
             `-lynx(5678)

	3. Move said programs to another Screen session:

$ screen -t vim 10 reptyr -V -- 2468
$ screen -t lynx 11 reptyr -V -- 5678

	4. Once all the programs are recovered, terminate their original
	   Screen instance:

$ kill -- 1234

	   (If the process was stopped before, as suggested above, also
	    resume it with $ kill -CONT , so it can process the signal
	    sent and terminate.)