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/
