FS#33697 - [linux] 3.6.x - 3.7.x File descriptor leak, probably inside the kernel not in userspace

Attached to Project: Arch Linux
Opened by Dan Fulger (dfulger) - Monday, 04 February 2013, 08:28 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 05 April 2013, 14:12 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
3.6.11-1-ARCH #1 SMP PREEMPT Tue Dec 18 08:57:15 CET 2012 x86_64
filesystem is NILFS2
lsof | wc run as root gives 12000 lines
cat /proc/sys/fs/file-nr
950816 0 2000000
It grew even over the weekend when the screen was locked. I had to increase the limit because I could not open sockets anymore.
cat /proc/sys/fs/file-nr before I incresead the limit:
949568 0 799307
(so it was already over the limit, something was incresing it that did not check the limit!)

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Friday, 05 April 2013, 14:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  Reopen if still valid.
Comment by Allan McRae (Allan) - Monday, 04 February 2013, 08:43 GMT
If you are reporting an issue that is probably in the kernel, it is a good idea to be running the up-to-date version from the repos...
Comment by Dan Fulger (dfulger) - Tuesday, 05 February 2013, 14:23 GMT
Aditional information from /proc/slabinfo (now at a little more than 105000 open files in /proc/sys/fs/file-nr)

kmalloc-512 1056192 1056192 512 32 4 : tunables 0 0 0 : slabdata 33576 33576 0
shmem_inode_cache 1056198 1056198 712 46 8 : tunables 0 0 0 : slabdata 42910 42910 0
kmalloc-256 1060397 1060480 256 32 2 : tunables 0 0 0 : slabdata 33143 33143 0
dentry 1071966 1071966 192 42 2 : tunables 0 0 0 : slabdata 25523 25523 0
radix_tree_node 1076919 1076943 568 28 4 : tunables 0 0 0 : slabdata 38748 38748 0
kmalloc-96 2057370 2057370 96 42 1 : tunables 0 0 0 : slabdata 48985 48985 0
Comment by Gerardo Exequiel Pozzi (djgera) - Friday, 08 February 2013, 17:17 GMT
  • Field changed: Summary (File descriptor leak, probably inside the kernel not in userspace → [linux] File descriptor leak, probably inside the kernel not in userspace)
  • Field changed: Status (Unconfirmed → Waiting on Response)
  • Field changed: Category (Packages: Core → Upstream Bugs)
  • Task assigned to Thomas Bächler (brain0), Tobias Powalowski (tpowa)
Please report to upstream if problem persist with 3.7.X (3.6.X branch is not maintained anymore), there is nothing to do here. Thanks.
Comment by Dan Fulger (dfulger) - Tuesday, 12 February 2013, 09:10 GMT
All symptoms disappeared after I logged out (and returned to the console where I executed startx). I will try now with a fully updated system.
Comment by Dan Fulger (dfulger) - Tuesday, 12 February 2013, 09:17 GMT
clarification: I had closed all applications before logout, and none of the symptoms had disappeared. Only on logout the dentries, file descriptors etc. were released.
Comment by Dan Fulger (dfulger) - Tuesday, 12 February 2013, 10:40 GMT
clarification: by the symptoms disappearing, I mean the number of file descriptors went down from 16 million to 576, and 20 GB of memory were released.
Comment by Dan Fulger (dfulger) - Wednesday, 13 February 2013, 08:07 GMT
After one day on the fully updated system (3.7.6-1-ARCH #1 SMP PREEMPT Mon Feb 4 09:15:13 CET 2013 x86_64) it seems the problem is still present.

lsof | wc run as root gives 14232 lines

cat /proc/sys/fs/file-nr
86944 0 799166

slabinfo seems similar though I cannot be sure this early

Dell Optiplex 790 with Intel video. KDE 4.10 from the update (it was KDE 4.9 before, same behaviour). I have used du and df before the update on all mounted tmpfs and I could not find any significant file leak.
Comment by Dan Fulger (dfulger) - Wednesday, 13 February 2013, 08:08 GMT
file-nr was 30304 yesterday and it grows almost constantly
Comment by Dan Fulger (dfulger) - Wednesday, 13 February 2013, 08:15 GMT
wc /proc/sysvipc/shm gives 48 lines
Comment by Dan Fulger (dfulger) - Wednesday, 13 February 2013, 08:41 GMT
wc /proc/[0-9]*/maps gives just 21 thousand lines
Comment by Dan Fulger (dfulger) - Thursday, 21 February 2013, 07:26 GMT
ran the commands again now that I am back at 700000 leaked file descriptors. wc /proc/sysvipc/shm gives 57 lines and wc /proc/[0-9]*/maps gives just 23 thousand lines. slabinfo shows the same leakage patter.
Comment by Dan Fulger (dfulger) - Thursday, 21 February 2013, 07:28 GMT
Also ran df -i and df -k, no leak in the RAM-based filesystems. Maybe I should run it with different options?
Comment by Dan Fulger (dfulger) - Monday, 25 February 2013, 07:31 GMT
I have restarted my computer before the weekend and did not start VMWare. And the leak did not reoccur. Now that I started VMWare Workstation again it seems to reappear. But, like I said before, when I shut down the Linux computer the memory/file descriptors are not released when I shut down VMWare (/etc/init.d/vmware stop, so I shut down everything including the daemons), only when I later shut down X. So maybe the VMWare GUI is triggering a bug in X or something like that?
Comment by Tobias Powalowski (tpowa) - Wednesday, 27 February 2013, 11:33 GMT
Status on 3.8?

Loading...