From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: When xterm starts the shell there are four open instances of the tty, there should only be three. This means the leaked fd may be inherited by any descendant from the xterm. Version-Release number of selected component (if applicable): xterm-179-6.EL How reproducible: Always Steps to Reproduce: 1. Start an xterm 2. Type: ls -l /prof/self/fd Actual Results: [kasperd@marvin kasperd]$ ls -l /proc/self/fd total 5 lrwx------ 1 kasperd kasperd 64 Nov 16 22:20 0 -> /dev/pts/3 lrwx------ 1 kasperd kasperd 64 Nov 16 22:20 1 -> /dev/pts/3 lrwx------ 1 kasperd kasperd 64 Nov 16 22:20 2 -> /dev/pts/3 lr-x------ 1 kasperd kasperd 64 Nov 16 22:20 3 -> /proc/3812/fd lrwx------ 1 kasperd kasperd 64 Nov 16 22:20 9 -> /dev/pts/3 [kasperd@marvin kasperd]$ Expected Results: [kasperd@marvin kasperd]$ ls -l /proc/self/fd total 5 lrwx------ 1 kasperd kasperd 64 Nov 16 22:20 0 -> /dev/pts/3 lrwx------ 1 kasperd kasperd 64 Nov 16 22:20 1 -> /dev/pts/3 lrwx------ 1 kasperd kasperd 64 Nov 16 22:20 2 -> /dev/pts/3 lr-x------ 1 kasperd kasperd 64 Nov 16 22:20 3 -> /proc/3812/fd [kasperd@marvin kasperd]$ Additional info: Some shells may close leaked filedescriptors hiding the symptoms of the xterm bug. However the symptoms are visible as long as bash is being used as shell.
Perhaps it depends on the kernel/pty implementation. On Debian/testing with 2.4.27, I see this: ~ (1) ls -l /proc//self/fd total 4 lrwx------ 1 tom tom 64 Nov 29 19:33 0 -> /dev/pts/4 lrwx------ 1 tom tom 64 Nov 29 19:33 1 -> /dev/pts/4 lrwx------ 1 tom tom 64 Nov 29 19:33 2 -> /dev/pts/4 lr-x------ 1 tom tom 64 Nov 29 19:33 3 -> /proc/8226/fd ~ (2)
Sorry - that was tcsh. With bash I see this (will check more). tom@crayon:/usr/build/xterm/xterm-196j$ ls -l /proc/self/fd total 5 lrwx------ 1 tom tom 64 Nov 29 19:35 0 -> /dev/pts/5 lrwx------ 1 tom tom 64 Nov 29 19:35 1 -> /dev/pts/5 lrwx------ 1 tom tom 64 Nov 29 19:35 2 -> /dev/pts/5 lr-x------ 1 tom tom 64 Nov 29 19:35 3 -> /proc/8235/fd lrwx------ 1 tom tom 64 Nov 29 19:35 9 -> /dev/pts/5 tom@crayon:/usr/build/xterm/xterm-196j$
File-descriptor 9 appears to be the one opened in main.c by this chunk: if ((pty_name = ptsname(screen->respond)) == 0) { SysError(ERROR_PTSNAME); } if ((ptyfd = open(pty_name, O_RDWR)) < 0) { SysError(ERROR_OPPTSNAME); } and ptyfd is used for a while before copying it to the tty variable. That is next updated by opening /dev/tty in a thicket of ifdef's. So it's simple to see, hard to fix (will study this and try to not break it ;-).
Does this occur in FC3 and/or other OS releases as well?
Probably (I verified this on Debian/testing). The related code hasn't changed for a while.
fixed: http://invisible-island.net/xterm/xterm.log.html#xterm_198
Thomas: You wouldn't happen to have a patch, or CVS diff of just the fix for this would you? If so, I can apply the fix alone for FC2 and FC3 and update them for those releases possibly. We'll put the new xterm into FC4 development soon too. Thanks. Setting to "NEEDINFO", to find out if there's a minimal patch available.
yes - I made a note to do this when I get home this afternoon
Thanks Thomas!
Created attachment 110537 [details] fix for file-descriptor leak. hmm - longer than I'd like, but that's because I changed a variable name (too many "tty" substrings to read).
Thanks for the patch Thomas, we'll review it for the next xterm update for FC.
xterm-209-2 in rawhide contains the upstream fix. Does this still need to be open, considering FC3 has reached its EOL?
I couldn't reproduce the problem with xterm-208-2.FC4
This is bug is fixed in all current versions of Fedora; it does not appear to affect RHEL-3, but does affect RHEL-4. Closing this bug, and cloning as a RHEL-4 bug.