Gdm opens a file descripor for logging and then uses dup2(2). However, the origianl file descriptor opened is not closed. The leak occurs when a user logs out of X and will continue untill gdm is restarted, usually when the system is rebooted. I believe this effects all versions of gdm to date. The following patch fixes this problem: diff -ruN gdm-2.0beta2.orig/daemon/server.c gdm-2.0beta2.new/daemon/server.c --- gdm-2.0beta2.orig/daemon/server.c Sat Dec 23 17:02:11 2000 +++ gdm-2.0beta2.new/daemon/server.c Sat Dec 23 17:54:51 2000 @@ -96,6 +96,7 @@ if (logfd != -1) { dup2 (logfd, 1); dup2 (logfd, 2); + close (logfd); } else gdm_error (_("gdm_server_start: Could not open logfile for display %s!"), d->name); diff -ruN gdm-2.0beta2.orig/daemon/xdmcp.c gdm-2.0beta2.new/daemon/xdmcp.c --- gdm-2.0beta2.orig/daemon/xdmcp.c Sat Dec 23 17:02:11 2000 +++ gdm-2.0beta2.new/daemon/xdmcp.c Sat Dec 23 17:54:36 2000 @@ -750,6 +750,7 @@ if (logfd != -1) { dup2 (logfd, 1); dup2 (logfd, 2); + close (logfd); } else gdm_error (_("gdm_xdmcp_handle_manage: Could not open logfile for display %s!"), d->name);
Fixed in 7.0 *** This bug has been marked as a duplicate of 12301 ***
After comparing your gdm-2.0beta2-fdleak.patch from 7.0 and horms' patch above, you will find that you fixed one leak but not the other. The patch above also affects daemon/server.c, which yours does not. This bug should be reopened until the issue is fixed completely.
Ah, thanks. I went ahead and changed the patch to have the second close().
Any idea when we can expect a new SRPM, or what it will be called? Thanks....
It'll be in the next beta