[screen-devel] [bug #52545] vbell doesn't work, plus multiple bells cause a long lockup

[Egmont Koblinger]

URL:
  <http://savannah.gnu.org/bugs/?52545>

                 Summary: vbell doesn't work, plus multiple bells cause a long
lockup
                 Project: GNU Screen
            Submitted by: egmont
            Submitted on: Tue 28 Nov 2017 10:55:50 AM UTC
                Category: Crash/Freeze/Infloop
                Severity: 3 - Normal
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: Cur Dev Sources
           Fixed Release: None
         Planned Release: None
           Work Required: None

    _______________________________________________________

Details:

With "vbell on" in screenrc, emit a hundred BELs in a row:

for i in {1..100}; do echo -ne '\a'; done

Notice that:
 - screen locks up and becomes unusable for 10 seconds,
 - and by the way, no visual bell is presented.

The lockup is, needless to say, pretty bad, and its duration increases
proportionally to the number of BELs emitted (e.g. accidentally by cat'ing a
binary file): a tenth of second for each BEL.

strace'ing reveals the following:

The first one or two BELs are handled separately, and then the rest in a
single step. There's a

read(5, "\0\7\7\7\7\7\7\7 [...]

reading 98 or 99 BELs (the initial \0 is irrelevant, it's due to TIOCPKT),
followed by 98 or 99

nanosleep({tv_sec=0, tv_nsec=100000000}, [...]

in a row which causes the 10 second delay, followed by

write(3, "\33[?5h\33[?5l\33[?5h\33[?5l\33[?5h\33[?5l [...]

toggling reverse video 98 or 99 times.

In xterm, the screen goes reverse maybe once or twice during processing these
hundred BELs. In gnome-terminal it doesn't go reverse at all. I don't think
it's feasible to expect that termial emulators will increase the duration of
reverse video if they immediately encounter the sequence that turns it off.

I believe the whole point of the 0.1 second sleeps is that for a visual bell,
the terminal should be set to reverse, then wait this much, and then restored
to non-reverse video.

To address both issues, upon encountering a BEL the following should happen:
 - enable reverse video,
 - set an asynchronous timer for 0.1 seconds later,
 - continue processing input,
 - a subsequent BEL may or may not extend the timer, but there should be at
most 1 timer at a time,
 - once the timer elapses, restore non-reverse video.

None of these issues happen with "vbell off", that is, no nanosleep() and no
"\33[?5h\33[?5l" encountered in strace's log, and the for-loop finishes
instantly.

Tested with 4.6.1 and git master.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52545>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/