GNOME Bugzilla – Bug 730220
Doesn't properly update display after cating binary stuff
Last modified: 2014-05-17 11:48:16 UTC
- Download and uncompress the binary file "socat" from https://bugs.kde.org/show_bug.cgi?id=334432 - Start vte or g-t - execute "cat socat" - wait until completes (stops), note: you may not see the prompt because some of the escape sequences caused data to be injected as if it was typed - press ^C to drop that data, the prompt appears - execute "konsole --version", and repeat this step if necessary In about half of the cases, three lines (qt, kde, konsole version) are printed and the prompt correctly appears. In the other half of the cases, nothing seems to happen, as if konsole hung. However, any keypress (even a backspace) or dragging the scrollbar causes konsole's output and the prompt to appear.
If you redirect the output: "konsole --version > /tmp/konsoleversion", you'll still face the vte bug: the prompt is not always displayed. If you check the output file's timestamp and content (it's recent and contains the full version info) and ps for konsole (it's not running) you'll find that konsole has already completed its task and quit. If you make your bash prompt store the timestamp somewhere (e.g. PS1='blahblah $(date > /tmp/xx) blah'), you'll see that bash has already printed the new prompt, it's just not shown by vte. If you execute "cat /tmp/konsoleversion", vte always updates the display correctly. However, something like "sleep 0.05; cat /tmp/konsoleversion" sometimes triggers the bug. So timing does matter a lot. Even simpler test case: just execute "sleep 0.05", sometimes the prompt doesn't appear.
When the bug occurs, highlighting the last (empty) line with mouse doesn't change anything. So it's not a display update, it's probably that vte hasn't even processed that incoming data.
Created attachment 276632 [details] test file 'socat' Here's a smaller test file, cut out from the original. A few random bytes at the beginning, then the rest is ascii words separated by '\0'. I'm not able to cut its size to below 8KB. (Well, a tiny little bit under 8KB, but with shell prompt and so on it probably exceeds that limit.) It's at least suspicious. I hope we're not dealing with another kernel bug/limitation as in bug 539312.
Hmmm, seems like it has something to do with the UTF-8 decoder. The first byte of a multibyte sequence, followed by NUL, followed by ~8K normal ascii characters triggers the bug: echo -ne '\xC0\x00'; for i in {5..9000..5}; do printf %5s $i; done The first 2 bytes, and the next 8174 bytes seem to get swallowed, the rest is printed ("5 8180 8185 8190 8195 8200 [...]") and the buggy behavior starts. But a bug in the decoder wouldn't explain how dragging the scrollbar can have any effect on the terminal's contents. Weird...
Correcting myself: keyboard input does *not* fix the display. In case of an invisible bash prompt, pressing backspace fixed the display because bash rang the bell. Placing "set bell-style none" in .inputrc changes backspace not to fix the display. Similarly, "sleep 0.05; echo foo; cat" sometimes doesn't display "foo", in that case backspace doesn't repair the screen. "sleep 0.05; passwd" sometimes doesn't show the pw changing instructions, and then you can type your old password without the display being updated.
Created attachment 276640 [details] [review] The Fix Okay, so as it turns out, g_utf8_validate() and g_utf8_get_char_validated() don't handle the NUL byte properly. Here's a fix. I'll double check it tomorrow, write unittests etc.
Created attachment 276667 [details] [review] The Fix v2 Fix, 2nd version. Bit of cleanup, unittests.