GNOME Bugzilla – Bug 622180
Frozen parts of filesystem freezes gnome-terminal
Last modified: 2012-06-04 22:10:26 UTC
Steps to reproduce: 1. Open gnome-terminal 2. mkdir tmp 3. fusexmp_fh tmp 4. cd tmp 5. killall -STOP lt-fusexmp_fh # make "tmp" directory frozen 6. Attempt to open a new tab. What happens: gnome-terminal freezes all tabs and all windows, including menu. What should happen: gnome-terminal opens new tab, may be with frozen bash, but other tabs and windows works as before, e.g. one flawed tab should not freeze the whole gnome-terminal. Use "killall -CONT lt-fusexmp_fh" or abort this FUSE filesystem to unfreeze.
Which version of vte and gnome-terminal? Please attach a backtrace of the hanging process.
No response; closing. If you can provide the necessary information, please re-open the bug.
It's not one frozen tab problem here I guess. vte relies on /tmp working. I don't think we have to support such broken systems.
Oh, sorry. My bad. It's not /tmp! I think the problem is that the new tab is opened in the same directory. Probably bash not loading, not our problem.
bash not loading, but _all tabs_ are frozen (not just the newly created one). One tab hangs the whole gnome-terminal.
Which version of vte and gnome-terminal? Please attach a backtrace (all threads) of the hanging process.
Probably hang in "cd".
Hmm right. terminal-screen.c:cwd_of_pid() calls readlink, or, if that fails, chdir.
We're not supposed to get to that hack on Linux though, right? Vitaly, can you attach to the process and see where it's getting stuck?
@Vitaly: Ping?
+ Trace 228954
Check something more?
This will be fixed by the vte & g-t changes in bug 675987. *** This bug has been marked as a duplicate of bug 675987 ***