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

>>>>> On 2004-04-06 22:31:43 -0400, Allan Wind wrote:

 > 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.)

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Reply via email to