ITerm does not drop tty connections when closing windows
By gnach... on September 06, 2010 20:01 (imported from Google Code)
From http://sourceforge.net/tracker/?func=detail&aid=2900888&group_id=67789&atid=518973
System: Mac Pro OS X 10.6.2
iTerm version: 0.10
Summary: When quitting iTerm or closing a Window, the open terminal
connections are not dropped properly. Although the /dev/ttys00? disappear,
they remain visible by the "uptime" or "w" command.
This only happens when using QUIT or clicking the red (x) button on the
window or using Cmd-W. When closing the terminals with Ctrl-D, they also
disappear from uptime.
Steps to reproduce:
- Make sure no Terminal or iTerm is open
- Open Console
- Open iTerm
Console will report: login[aaa] USER_PROCESS: aaa ttys000
- Open a second window or tab in iTerm
Console will report: login[bbb] USER_PROCESS: bbb ttys001
- Type "uptime" in any of the two iTerm windows. It will report:
hh:mm up .... 3 users .....
- Close the first iTerm window using Cmd-W
Console reports nothing
- Type "uptime" in the other window. It will report:
uptime: /dev/ttys000: No such file or directory
hh:mm up .... 2 users ....
- Close the second iTerm window using Ctrl-D
Console reports: login[bbb] DEAD_PROCESSS: bbb ttys001
This shows that somehow the tty session is not properly terminated when
using Cmd-W (or Cmd-Q).
The ttys000 will be reclaimed when opening a new iTerm window.
Note that the default command when opening an iTerm window is "login -fp
$USER", which may be related to the cause of this behaviour.
This report is similar to bug report 1011909 that was purportedly fixed on
2005-04-04 and bug report 2791726 that was closed for some strange reason on 2009-10-03
---
I can confirm this. Additionally, Cmd-W to close a tab or closing a second
window also quits the entire application for me. I enabled logging and saw
a bad file descriptor error message printed from PTYTask.m TaskNotifier
run() after the polling select fails with EBADF which leads to an exit. It
was introduced in rev 1789. It looks like a race condition between
theTaskNotifier thread calling select and the main thread calling
deregister.