GNOME Bugzilla – Bug 730643
gnome-terminal suddenly stops to accept input (for all instances)
Last modified: 2021-06-10 20:46:52 UTC
Since upgrading to Ubuntu 14.04 it often happens that gnome-terminal stops accepting input, which affects all running (and new) instances of gnome-terminal. stracing the gnome-terminal process repeats the following output: 19279 restart_syscall(<... resuming interrupted call ...> <unfinished ...> 19276 restart_syscall(<... resuming interrupted call ...> <unfinished ...> 19275 restart_syscall(<... resuming interrupted call ...> <unfinished ...> 19274 restart_syscall(<... resuming interrupted call ...>) = 1 19274 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\36\0\343\371\230\245I\5\3\0`\2\3\0\240\1\350\1\0\0]\1\0\0\211\1\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 19274 recvmsg(6, 0x7ffff376caa0, 0) = -1 EAGAIN (Resource temporarily unavailable) 19274 poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLOUT}]) 19274 writev(6, [{"\22\0x\0\3\0\240\1\211\1\0\0]\1\0\0\10\4\6\0\307\1\0\0+ sudo /home/daniel/Vcs/bup/bup index -v -u --long --exclude-from=/home/daniel/.cache/find-for-backup.exclude.bup / /home\nTraceback (most recent call last):\n File \"/home/daniel/Vcs/bup/bup\", line 26, in <module>\n from bup import helpers\n File \"/home/daniel/Vcs/bup/lib/bup/helpers.py\", line 217, in <module>\n def batchpipe(command, args, preexec_fn=None, arg_max=_helpers.SC_ARG_MAX):\nAttributeError: 'module' object has no attribute 'SC_ARG_MAX'\n\2\31\0\v\0\3\0\240\1\0\0\0\0\37\0\0\0\230\245I\5\3\0\240\1\350\1\0\0]\1\0\0\211\1\0\0\0\0\0\0\0\0\0\0+\0\1\0", 528}, {NULL, 0}, {"", 0}], 3) = 528 19274 poll([{fd=6, events=POLLIN}], 1, 4294967295) = 1 ([{fd=6, revents=POLLIN}]) 19274 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\1\2\346\371\0\0\0\0\5\0\300\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 19274 recvmsg(6, 0x7ffff376c540, 0) = -1 EAGAIN (Resource temporarily unavailable) 19274 recvmsg(6, 0x7ffff376c540, 0) = -1 EAGAIN (Resource temporarily unavailable) 19274 recvmsg(6, 0x7ffff376ca80, 0) = -1 EAGAIN (Resource temporarily unavailable) 19274 poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}, {fd=3, events=POLLIN}, {fd=38, events=POLLIN}, {fd=11, events=POLLIN}, {fd=15, events=POLLIN}, {fd=19, events=POLLIN}, {fd=21, events=POLLIN}, {fd=37, events=POLLIN}, {fd=30, events=POLLIN}, {fd=46, events=POLLIN}, {fd=25, events=POLLIN}], 12, 4294967295) = 1 ([{fd=6, revents=POLLIN}]) 19274 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"\36\0\346\371\220\247I\5\3\0`\2\3\0\240\1\350\1\0\0]\1\0\0\211\1\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 19274 recvmsg(6, 0x7ffff376caa0, 0) = -1 EAGAIN (Resource temporarily unavailable) 19274 poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLOUT}]) 19274 writev(6, [{"\22\0x\0\3\0\240\1\211\1\0\0]\1\0\0\10\4\6\0\307\1\0\0+ sudo /home/daniel/Vcs/bup/bup index -v -u --long --exclude-from=/home/daniel/.cache/find-for-backup.exclude.bup / /home\nTraceback (most recent call last):\n File \"/home/daniel/Vcs/bup/bup\", line 26, in <module>\n from bup import helpers\n File \"/home/daniel/Vcs/bup/lib/bup/helpers.py\", line 217, in <module>\n def batchpipe(command, args, preexec_fn=None, arg_max=_helpers.SC_ARG_MAX):\nAttributeError: 'module' object has no attribute 'SC_ARG_MAX'\n\2\31\0\v\0\3\0\240\1\0\0\0\0\37\0\0\0\220\247I\5\3\0\240\1\350\1\0\0]\1\0\0\211\1\0\0\0\0\0\0\0\0\0\0+\0\1\0", 528}, {NULL, 0}, {"", 0}], 3) = 528 It seems to constantly write something to fd=6, but does not receive a (proper) response?! The text used therein was the output of some command I've run before, but which is not visible anymore. I have tried the "Reset" and "Reset and Clear" entries from the "Terminal" menu entry, but while it clears the screen, the shell prompt won't appear and the issue gets not fixed. I have to close all terminal instances (or kill gnome-terminal), which is really annoying. This happens with Ubuntu's gnome-terminal 3.6.2-0ubuntu1, but also with 3.12.2-1 from Debian. A bug with similar symptoms has been reported in Launchpad for 2.32.0-0ubuntu1.1 already: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/799019 For me this started to happen only after upgrading to Ubuntu 14.04.
Created attachment 277074 [details] strace of the gnome-terminal process
I have set scrollback to "Unlimited" in the gnome-terminal profile. Maybe this is relevant?!
Is /tmp or /var/tmp (nearly) out of disk space?
Not currently, and unlikely that it was, but I will look at it when it happens again. % df -h | grep /tmp tmpfs 3,9G 110M 3,8G 3% /tmp tmpfs 3,9G 72K 3,9G 1% /var/tmp Is there anything else that I should look at?
It just happened again, while I tried to reproduce what I was doing this afternoon and had 'watch "df -h | grep /tmp"' running in a gnome-terminal instance. I am attaching the output of strace again.
Created attachment 277084 [details] Another strace capture.
fd 6 is the local socket to X: socket(PF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC, 0) = 6 connect(6, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0 getpeername(6, {sa_family=AF_LOCAL, sun_path=@"/tmp/.X11-unix/X0"}, [20]) = 0 Why does it contain data that resides in your terminal ("sudo /home/daniel/Vcs/bup/bup ...")? My only guess is that it's the selection/paste data. Is there any chance the given data was indeed highlighted with your mouse? Next time such a hang occurs, could you please try to select something in g-t with the mouse, and Shift+Insert into an xterm, to see if it works? My other guess was, starting with the "infinite scrollback" idea is that we may have an overflow at int32 or uint32, but that'd require to produce heavy output for an hour or two, and would cause a much higher disk usage in /tmp. So I guess it's irrelevant. If indeed something communicating with the X server goes wrong then I'm afraid it's more likely a Gtk or X issue rather than g-t/vte.
From which ubuntu did you upgrade to trusty? If it's saucy, it could help if you downgraded your libvte-2.90* and gnome-terminal* packages to their saucy version and tell us if you still experience hangs.
> Why does it contain data that resides in your terminal ("sudo /home/daniel/Vcs/bup/bup ...")? My only guess is that it's the selection/paste data. Is there any chance the given data was indeed highlighted with your mouse? That's the case, yes. Also for the second strace output, where I've copied the output from "df". > Next time such a hang occurs, could you please try to select something in g-t with the mouse, and Shift+Insert into an xterm, to see if it works? It still works then. > "infinite scrollback" I have changed this setting to "100000" lines, and it still happened. > If indeed something communicating with the X server goes wrong then I'm afraid it's more likely a Gtk or X issue rather than g-t/vte. Could it be that the problem resides from the gnome-terminal instance being closed already, which contained the X selection? I am not sure, but in both cases I could not find the instance containing the selection anymore. Maybe the issue also gets triggered by the selection being scrolled off? In the last two cases where this happened I've called my backup script, which causes a lot of output (via "find" and "bup", with stdout/stderr redirection being involved). For now, I am downgrading libvte and gnome-terminal to the versions from Saucy: The following packages will be DOWNGRADED: gnome-terminal [3.12.2-1 -> 3.6.1-0ubuntu6] gnome-terminal-data [3.12.0-2 -> 3.6.1-0ubuntu6] libvte-2.90-9 [1:0.36.2-1ubuntu1 -> 1:0.34.6-1ubuntu1] libvte-2.90-common [1:0.36.2-1ubuntu1 -> 1:0.34.6-1ubuntu1]
(In reply to comment #9) > Could it be that the problem resides from the gnome-terminal instance being > closed already, which contained the X selection? I am not sure, but in both > cases I could not find the instance containing the selection anymore. Yup it's indeed something that we should verify - the strange thing is, however, that as seen in strace, g-t still remembers that selection data perfectly, just fails to push it to X. Also, why would it push it to X if you're not modifying the selection right now. > Maybe the issue also gets triggered by the selection being scrolled off? Could be - but you used to have infinite scrollback and it still occurred. Or maybe we're on a completely wrong track... I think we'd need a reproducible test case, that'd help a lot. I also have ubuntu trusty (although newer vte/g-t), but I've never seen such a hang.
It now happened also with the downgraded packages.. OBSERVATIONS (you may want to skip to WORKAROUND): ============ The strace output seems to look similar. I have noticed this time, that it's possible to still paste input to gnome-terminal! (from both X selection and the clipboard). So it's at least possible to exit open terminal sessions gracefully (when pasting also newline characters). It appears that "only" the keyboard input is lost. I am using ClipIt (1.42) to manage my clipboard data, and it contains the selection that gnome-terminal seems to constantly push. ClipIt appears to be the reason for the selection to appear so frequently in the strace output. It looks like it regularly polls it. Exiting ClipIt makes the strace output less verbose, but gnome-terminal still won't accept keyboard input. The strace output then basically contains only: [pid 20287] 17:26:40.976268 inotify_add_watch(16, "/usr/share/awesome-gnome-dev/applications", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory) [pid 20287] 17:26:40.976491 poll([{fd=14, events=POLLIN}, {fd=16, events=POLLIN}], 2, 3996) = 0 (Timeout) "awesome-gnome-dev" is my custom name for the session(?) desktop file. % env|grep awesome-gnome-dev DEFAULTS_PATH=/usr/share/gconf/awesome-gnome-dev.default.path GDMSESSION=awesome-gnome-dev XDG_CONFIG_DIRS=/etc/xdg/xdg-awesome-gnome-dev:/etc/xdg MANDATORY_PATH=/usr/share/gconf/awesome-gnome-dev.mandatory.path DESKTOP_SESSION=awesome-gnome-dev XDG_DATA_DIRS=/usr/share/awesome-gnome-dev:/usr/share/gnome:/usr/local/share/:/usr/share/ WORKAROUND ========== I could re-activate the "frozen" g-t instances by stopping "ibus" ("ibus exit"). I then launched "Keyboard Input Methods", which stated that "Keyboard Input Methods (IBus Daemon) is not running. Do you wish to start it?", and I started it. I am not sure if "ibus exit" already fixed it, but probably not. I have now used "im-config" to select "none" as user preferences, hopefully this will prevent ibus from being started/used.
Could this be that the input method is broken in Ubuntu? See https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1263249 for a perhaps related story – in that case, keyboard stops so that I basically cannot type into any other apps.
Following the idea that your issue might be related to the link I've just posted, could you please re-enable "ibus" im method, and if you're facing the bug again they try: - whether typing to other Gtk+ apps work at all (I can't type to most apps when that bug happens) - whether giving focus to a "konsole" window and back to gnome-terminal makes it possible to type again (it does for me – I recommend to start a konsole in advance) - whether changing keyboard layout makes it possible to type again (it does for me – again, I recommend to set up at least 2 kbd layouts in advance) Also I'd like to hear whether setting "none" as input method made the problem go away for you.
ibus is getting more and more suspicious to me :) https://code.google.com/p/ibus/issues/detail?id=1715 Was there maybe any special keypress (or sequence of keypresses) that triggered gnome-terminal no longer accepting input? It doesn't matter if not pressed in gnome-terminal, if pressed in another application of ibus method then it also counts. Or something that you accidentally pressed something you didn't intend, like maybe your hand slipped and you don't even know what you pressed?
FWIW I've been getting something similar on rawhide in the last week or so. It happens rarely, I think semwhow related to just exiting a terminal session or something like that.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7455.