Description of problem: Occasionally (every few days) I find that gnome-terminal stops responding to input, either from the keyboard or from its ttys. When this happens, all Terminal windows are stuck and gnome-terminal-server starts busy-looping. strace reveals that gnome-terminal-server is repeatedly calling poll(), with one file descriptor available to read... but no system calls are made on it. Stepping through in gdb it seems that the loop is simply the g_main_loop, but for some reason no callback is called. I haven't worked out what's up. Version-Release number of selected component (if applicable): gnome-terminal-3.14.2-1.fc21.x86_64 How reproducible: Occasional.
Sounds the same as https://bugzilla.gnome.org/show_bug.cgi?id=735101. At this moment unfortunately we have no idea what the problem could be, and I haven't been able to reproduce in the last couple of months. Any help (especially a way to quickly trigger this bug) would be highly appreciated.
I just upgraded to F21 and get this bug a few times a day. It triggers on me when I close a lot of windows quickly. Sometimes while closing, sometimes while opening a new one immediately after closing. However, try as I might with scripts opening a lot of windows, etc, I can't reproduce this bug on demand. I have a little hunch, I use tcsh and perhaps if the tcsh SIGINT code is slow-ish to run that is screwing up gnome-terminal's timing with some sort of race condition. I suspect this because it only happens after using the windows to some degree, and my tcsh is set to merge histories back into .history, non-trivial with 10000 entries. Maybe that's why my scripted open/close tests don't trigger the bug, because tcsh detects no history merge required. Just a guess. I mostly get this when I am about to reboot my computer and I go to all my workspaces ^D'ing all shell windows very quickly, like maybe 30 in 1 minute. strace for me shows similar output: stuck on poll. Since it happens often for me, perhaps I could run the server (if even possible) in gdb or strace to see what it is doing *before* it sticks on poll. Would I need debuginfo stuff for that? Also related, which I've noticed since at least F20, maybe even F19, is that sometimes when opening a new window, it will open the frame/window but will not fill in any contents for 6 to 30s. I thought it was because something was swapped out (but I have gobs of ram), but now I think it is possibly related to this bug. It's tough to catch but next time that happens I'll see if I can strace. My hunch here is that it is doing a zillion polls but somehow recovering.
(In reply to Trevor Cordes from comment #2) > Also related, which I've noticed since at least F20, maybe even F19, is that > sometimes when opening a new window, it will open the frame/window but will > not fill in any contents for 6 to 30s. I believe this is the same as https://bugzilla.gnome.org/show_bug.cgi?id=730763. I don't think these two bugs are connected, but who knows.
(In reply to Trevor Cordes from comment #2) > I have a little hunch, I use tcsh and perhaps > if the tcsh SIGINT code is slow-ish to run that is screwing up > gnome-terminal's timing with some sort of race condition. I suspect this > because it only happens after using the windows to some degree, and my tcsh > is set to merge histories back into .history, non-trivial with 10000 > entries. I don't think so. First you press Ctrl-D which has no special meaning whatsoever to gnome-terminal (it doesn't mean "the app is about to terminate"), it just forwards it to your tcsh just as any other keypress. Then tcsh saves your history, it's again no different in g-t's eyes than any other operation tcsh could do. Then later at some point tcsh quits which is an atomic operation, and that's where g-t gets notified that it should clean up. I'm totally puzzled :(
(In reply to Egmont Koblinger from comment #3) > (In reply to Trevor Cordes from comment #2) > > > Also related, which I've noticed since at least F20, maybe even F19, is that > > sometimes when opening a new window, it will open the frame/window but will > > not fill in any contents for 6 to 30s. > > I believe this is the same as > https://bugzilla.gnome.org/show_bug.cgi?id=730763. What I see is *definitely* not 730763. There is no lag or delay on char input, I don't even get the initial window paint! I just get the frame with a solid color (like white or grey) window content (not my normal color). I'm pretty sure I get 100% CPU also, but can't confirm yet. Then, after X seconds I get a perfectly normal, usable, non-laggy terminal. 730763 I'll read further and contribute as I think I have seen this bug, but only after terminal prints non-ascii chars, like doing "cat /bin/ls" or something equally stupid. > I don't think these two bugs are connected, but who knows. I'm going to try to get an strace (quick!) next time my new term window does its 6-30s hang. 6s isn't much time to figure out ps # and strace, but 30s is.
I got it too - it is very random and can as bad as no working terminal and opening new ones not working at all to as little as just one window unresponsive and everything working after closing it. I almost always get it - it is just a question of time. Using Nvidia drivers.
@Jacek: Unfortunately I face this bug very rarely (once every couple of months) which pretty much prevents me from doing real investigation. If you could help us, that would be highly appreciated! See https://bugzilla.gnome.org/show_bug.cgi?id=735101. First, could you please install the wrapper script (e.g. in your ~/bin) from comment #37 and start gnome-terminal via that (and verify that by the existence of /tmp/g-t-s.log); and when it freezes then attach that logfile? Second, as per comment #40 please add an ''export GDK_CORE_DEVICE_EVENTS=1'' as the 2nd line of that script (verify by checking gnome-terminal-server's /proc/xxx/environ or if you use touchpad then scrolling no longer should be smooth 1 line at a time but 3-4 lines at once). Does the freeze still happen in this case? If you have any findings, it would be easier for us if you commented in Gnome's bugzilla rather than here, thanks!
OK, my script looks like this: #!/bin/bash export GDK_CORE_DEVICE_EVENTS=1 if ! pidof gnome-terminal-server >/dev/null; then echo -------------- >> /tmp/g-t-s.log GNOME_TERMINAL_DEBUG=all /usr/libexec/gnome-terminal-server >>/tmp/g-t-s.log 2>&1 & sleep 0.2 fi exec /usr/bin/gnome-terminal.orig "$@" Also - the problem in my case happens mostly in the terminals that have not been used in a while.
OK in my case this is not my problem. I've observed it for a longer time and it is all stalled ssh. Though I have no idea while all in a sudden my terminals get stalled so much.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is fixed upstream many months back. The latest Fedora 21 version has the fix. This bug does not occur anymore. Owner/Assignee can close this bz.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.