This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 139597 - file descriptor leak
file descriptor leak
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks: FC3Update 185596
  Show dependency treegraph
 
Reported: 2004-11-16 16:21 EST by Kasper Dupont
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version: xterm-198+
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-15 19:19:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
fix for file-descriptor leak. (9.28 KB, text/plain)
2005-02-01 20:19 EST, Thomas E. Dickey
no flags Details

  None (edit)
Description Kasper Dupont 2004-11-16 16:21:16 EST
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.
Comment 1 Thomas E. Dickey 2004-11-29 19:31:03 EST
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) 
Comment 2 Thomas E. Dickey 2004-11-29 19:32:55 EST
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$ 


Comment 3 Thomas E. Dickey 2004-11-29 20:25:57 EST
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 ;-).
Comment 4 Mike A. Harris 2004-12-22 08:47:40 EST
Does this occur in FC3 and/or other OS releases as well?
Comment 6 Thomas E. Dickey 2004-12-22 08:53:28 EST
Probably (I verified this on Debian/testing).
The related code hasn't changed for a while.
Comment 8 Thomas E. Dickey 2005-01-16 10:02:36 EST
fixed:
http://invisible-island.net/xterm/xterm.log.html#xterm_198
Comment 10 Mike A. Harris 2005-02-01 05:37:03 EST
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.
Comment 11 Thomas E. Dickey 2005-02-01 06:10:01 EST
yes - I made a note to do this when I get home this afternoon
Comment 12 Mike A. Harris 2005-02-01 06:15:37 EST
Thanks Thomas!
Comment 13 Thomas E. Dickey 2005-02-01 20:19:23 EST
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).
Comment 14 Mike A. Harris 2005-02-07 20:43:03 EST
Thanks for the patch Thomas, we'll review it for the next xterm
update for FC.
Comment 20 Miloslav Trmač 2006-03-05 06:52:20 EST
xterm-209-2 in rawhide contains the upstream fix.

Does this still need to be open, considering FC3 has reached its EOL?
Comment 21 Kasper Dupont 2006-03-05 11:13:28 EST
I couldn't reproduce the problem with xterm-208-2.FC4
Comment 22 Jason Vas Dias 2006-03-15 19:14:43 EST
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.

Note You need to log in before you can comment on or make changes to this bug.