I have a directory made from an old extracted Japanese zip, which due to
their non-UTF-8 locale, created b0rked directory names. I noticed during
rsync backups with --progress specified that the output would freeze as
one directory was entered, with roxterm using 100% CPU (rsync did
continue to run producing output but it never showed).

While it doesn't recreate the freeze, the following test does stall
output to the terminal until you SIGINT it:

======================================================================

while true; do echo '(ŽÊ^W) ‚Ù‚µ‚Ì‚ ‚« uAn Adult Akiv'; sleep 1; done

======================================================================

XFCE4's Terminal has no problems echoing this.

Is this a bug for you? If not I'll just fix the directories and move on.

Thanks
Debian Release: stretch/sid
  990 testing         www.deb-multimedia.org
  990 testing         10.1.0.3
  500 unstable        10.1.0.3
  500 quodlibet-unstable 10.1.0.3
    1 experimental    10.1.0.3
--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

reassign 799802 libvte-2.91-0
thanks

[Snip]

I can reproduce the symptoms in gnome-terminal too, so I think it's a
vte bug. The reason XFCE4 is OK with it is probably because it uses GTK2
and the corresponding older generation of vte.

Hi,

I cannot reproduce the issue -- in fact, I came across it on the
bugs.debian.org website which is encoded in UTF-8 so it cannot represent
the non-UTF-8 you're talking about. I'm copy-pasting the command but it's
perfectly valid UTF-8 and no lockup happens. It would be great if you could
construct a command line that emits such locking non-UTF-8 (e.g. echo
"\x12\x34..."), whereas the command itself can be copy-pasted from UTF-8
websites.

That being said, I suspect that this bug might be the same as (or similar
to)
https://bugzilla.xfce.org/show_bug.cgi?id=13383
https://bugzilla.gnome.org/show_bug.cgi?id=777733
https://bugzilla.gnome.org/show_bug.cgi?id=730154 comments 4-7

although that wouldn't explain the 100% CPU usage.

cheers,
egmont