GNOME Bugzilla – Bug 127870
terminal garbled and needs 'reset' after cat'ing file
Last modified: 2008-11-29 21:57:02 UTC
(This bug report was generated by Bug Buddy 2.2.104) tried to cat some file that somehow got named to /usr/local/share/pixmaps, and gnome-terminal crashed Debugging Information: Backtrace was generated from '/usr/bin/gnome-terminal' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 1029)] 0x408db7f7 in waitpid () from /lib/i686/libpthread.so.0
+ Trace 42054
Thread 1 (Thread 16384 (LWP 1029))
Created attachment 21788 [details] the file
catting random bits to a terminal is not a good idea in general ;) gnome-terminal should not segfault, though. I do not get a crash in 2.5.* by catting the file. Also, the stack trace attached seems to be corrupted, as vte_terminal_get_emulation does not call itself. Reporter: do you see this crash every time you cat the file? Anc can you tell us what version you are using (you should find the full version number in the /Help/About menu
I am running version 2.2.1. And catting or lessing this file only seems to crash the terminal every so often.
No crash here, but it does make the terminal garbled beyond repair. Still crashing on your end?
I'm getting the same results as Kjartan. No crash after a few cats but unrecoverable garbage each time.
I cannot get g-t to crash by catting the file. It does garble the terminal, but that is sort of inevitable; running reset fixes it for me, though. The stacktrace is pretty broken by the time vte_terminal_get_emulation is run.
xterm seems to be handling this just fine so it's clear gnome-terminal could do better here. It's not crashing though.
No crash here either (2.13). xterm displays rectangles instead of trying to convert each byte sequence (interpreting the strings using the current locale setting I thinkg) to a real glyph.
I hit this every other day and it's damn annoying. I used to believe that this is ISO 2202 in action. Which is, you can change charset using escape sequences. Xterm doesn't suffer, simply because xterm does not implement this and let it be done in an application called 'luit', which is like screen, but it does charset conversion. I trimmed the test case down, and apparently it's a single character that garbles! U+000E SHIFT OUT. You can garble your screen using: echo -e '\016' and fix it by: reset A quick inspection suggests that indeed that's ISO 2022. One solution of course is to make distributions add charset-reset sequence in their prompt. Other than that not much can be done. I'm with turning ISO 2022 by default. It doesn't make much sense in the UTF-8 era afterall. What do people think?
Apparently the effect of '\016' is reversed by '\017'. Another bug is with some Asian spam I get, that change the terminal encoding such that I'll see all Asian characters. Again reset comes to the rescue. I think we should disable all charset switchings by default. Transfering to vte to add required support first.
*** Bug 350487 has been marked as a duplicate of this bug. ***
*** Bug 500695 has been marked as a duplicate of this bug. ***
*** Bug 525013 has been marked as a duplicate of this bug. ***
*** Bug 538181 has been marked as a duplicate of this bug. ***
*** Bug 121894 has been marked as a duplicate of this bug. ***
2008-11-29 Behdad Esfahbod <behdad@gnome.org> Bug 127870 – terminal garbled and needs 'reset' after cat'ing file * src/iso2022.c (_vte_iso2022_state_new): Initialize all four maps (G0, G1, G2, G3) in USASCII mode, like xterm does.