Run skype from ports. Login. Do while sleep 3; do lsof|grep skype|wc; done and watch the count climb. The same things happens with linux versions of thunderbird, firefox and opera and may be more. Fix: Revert /sys/compat/{linux,linprocfs} and /sys/i386/linux to about April 15th state. Recompile linux and linprocfs modules, reinstall them and reboot. How-To-Repeat: See above
Responsible Changed From-To: freebsd-ports-bugs->freebsd-bugs Not a ports issue (feel free to correct me)
State Changed From-To: open->feedback Is this still the case with a recent -current?
The original behaviour was believed to have been fixed in src/sys/compat/linux/linux_stats.c version 1.83 http://lists.freebsd.org/pipermail/freebsd-emulation/2006-May/002122.html http://lists.freebsd.org/pipermail/freebsd-emulation/2006-May/002127.html After the request for feedback (after the above messages), the following response was sent but seemingly never made it to PR trail http://lists.freebsd.org/pipermail/freebsd-bugs/2006-September/020014.html "I do not see the original behavoir but I do see a slow leak in skype. Every time a call is made (for example to the skype testing service) it leaks 10 to 15 descriptors to /dev/mixer0 + some more. About 75% opens are to /dev/mixer0. Still think this is an emulation problem not skype's. firefox etc. also seem to keep far too many files open. For example firefox has 500+ open descriptors) with 4 tabbed windows open. But in my limited testing can't tell if there is a leak. I am running linux_base-fc-4_7 on a one month old freebsd-current." Gavin
> > The original behaviour was believed to have been fixed in > src/sys/compat/linux/linux_stats.c version 1.83 > http://lists.freebsd.org/pipermail/freebsd-emulation/2006-May/002122.html > http://lists.freebsd.org/pipermail/freebsd-emulation/2006-May/002127.html > > After the request for feedback (after the above messages), the following > response was sent but seemingly never made it to PR trail > http://lists.freebsd.org/pipermail/freebsd-bugs/2006-September/020014.html > > "I do not see the original behavoir but I do see a slow leak > in skype. Every time a call is made (for example to the > skype testing service) it leaks 10 to 15 descriptors to > /dev/mixer0 + some more. About 75% opens are to /dev/mixer0. > Still think this is an emulation problem not skype's. > > firefox etc. also seem to keep far too many files open. For > example firefox has 500+ open descriptors) with 4 tabbed > windows open. But in my limited testing can't tell if there > is a leak. > > I am running linux_base-fc-4_7 on a one month old > freebsd-current." Sorry, somehow I missed your email originally and found it today by chance. I tested it with skype and there is still a leak of 10 descriptors each time the skype testing service is called. All of the additional open file descriptors are opens to /dev/mixer0. Now I am running linux_base-fc-4_9. I suspect the bug is in the emulation layer. To test you will need a skype account. Then fire it up, call skype testing service and the the whole transaction finish. Wait for another 3 minutes or so as some descriptors take a while to close. Then do lsof |grep skype > file1 now call it again. Wait for another 3 minutes or so and do lsof |grep skype > file2 file2 will have 10 more lines than file1. If you grep for mixer0, you will see 10 more lines in file2 than in file1.
On Thu, 2007-05-31 at 18:23 -0700, Bakul Shah wrote: > I tested it with skype and there is still a leak of 10 > descriptors each time the skype testing service is called. > All of the additional open file descriptors are opens to > /dev/mixer0. Now I am running linux_base-fc-4_9. I suspect > the bug is in the emulation layer. Is there any chance you could either test or get somebody else to test your demo under Linux just to rule out the possibility that it is a bug in skype? Thanks, Gavin
> Is there any chance you could either test or get somebody else to test > your demo under Linux just to rule out the possibility that it is a bug > in skype? I don't have a linux system handy at the moment.
State Changed From-To: feedback->open Submitter doesn't a comparison system to test, but it sounds as though this might still be a problem.
Responsible Changed From-To: freebsd-bugs->freebsd-emulation
This should be fixed in FreeBSD 7 as of November 2007: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ioctl.c.diff?r1=1.138;r2=1.138.2.1 Can you check this? -- << Marcin Cieslak // saper@system.pl >>
On Fri, 11 Jul 2008 23:02:36 +0200 Marcin Cieslak <saper@SYSTEM.PL> wrote: > > This should be fixed in FreeBSD 7 as of November 2007: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ioctl.c.diff > ?r1=1.138;r2=1.138.2.1 > > Can you check this? I couldn't test on the original machine with linux_base-fc-4 so I tested it on amd64 machine with linux_base-fc-8. Skype still seems to keep open far too many descriptors (480 compared to 140 on the mac) and this number goes up to 663 when making a skype test call but there seems to be no further leakage. Thanks!
I can confirm - skype does not leak descriptors after first call. Tested on 8-CURRENT. FreeBSD vbook.fbsd.ru 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Wed Oct 1 08:03:48 MSD 2008 root@vbook.fbsd.ru:/usr/obj/usr/src/sys/VBOOK i386 # pkg_info -I linux_base\* skype\* linux_base-f8-8_4 Base set of packages needed in Linux mode (for i386/amd64) skype-2.0.0.72,1 P2P VoIP software # sysctl compat.linux compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux # Analysis of open descriptors: $ lsof | fgrep skype | awk '{ print $9; }' | sort | uniq -c | sort -nr 88 16 /usr/home/vova/.kde/share/config/kioslaverc 16 *:35644 8 localhost:18001 8 10.30.1.111:24183->ppp85-140-221-4.pppoe.mtu-net.ru:23909 8 /usr/local/lib/X11/fonts/webfonts/verdanab.ttf 8 /usr/local/lib/X11/fonts/webfonts/verdana.ttf 8 /usr/local/lib/X11/fonts/bitstream-vera/VeraBd.ttf 8 /usr/local/lib/X11/fonts/bitstream-vera/Vera.ttf 8 /usr/local/bin/skype 8 /usr/home/vova/.Skype/nickname/voicemail256.dbb 8 /usr/home/vova/.Skype/nickname/user4096.dbb 8 /usr/home/vova/.Skype/nickname/user16384.dbb 8 /usr/home/vova/.Skype/nickname/user1024.dbb 8 /usr/home/vova/.Skype/nickname/transfer256.dbb 8 /usr/home/vova/.Skype/nickname/profile16384.dbb 8 /usr/home/vova/.Skype/nickname/message512.dbb 8 /usr/home/vova/.Skype/nickname/message4096.dbb 8 /usr/home/vova/.Skype/nickname/message256.dbb 8 /usr/home/vova/.Skype/nickname/message1024.dbb 8 /usr/home/vova/.Skype/nickname/index2.dat 8 /usr/home/vova/.Skype/nickname/contactgroup512.dbb 8 /usr/home/vova/.Skype/nickname/contactgroup256.dbb 8 /usr/home/vova/.Skype/nickname/chatsync/93/933e6de4e914de3f.dat 8 /usr/home/vova/.Skype/nickname/chatsync/90/90443626f418d589.dat 8 /usr/home/vova/.Skype/nickname/chatsync/57/57d806a6d7ff6809.dat 8 /usr/home/vova/.Skype/nickname/chatsync/56/56187794f108deaf.dat 8 /usr/home/vova/.Skype/nickname/chatsync/03/03d2e8678e8cb7ce.dat 8 /usr/home/vova/.Skype/nickname/chatmsg512.dbb 8 /usr/home/vova/.Skype/nickname/chatmsg256.dbb 8 /usr/home/vova/.Skype/nickname/chatmsg2048.dbb 8 /usr/home/vova/.Skype/nickname/chatmsg1024.dbb 8 /usr/home/vova/.Skype/nickname/chatmember256.dbb 8 /usr/home/vova/.Skype/nickname/chat512.dbb 8 /usr/home/vova/.Skype/nickname/chat4096.dbb 8 /usr/home/vova/.Skype/nickname/chat2048.dbb 8 /usr/home/vova/.Skype/nickname/callmember256.dbb 8 /usr/home/vova/.Skype/nickname/call256.dbb 8 /usr/home/vova 8 /usr/compat/linux/usr/lib/libstdc++.so.6.0.8 8 /usr/compat/linux/usr/lib/libfreetype.so.6.3.16 8 /usr/compat/linux/usr/lib/libfontconfig.so.1.0.4 8 /usr/compat/linux/usr/lib/libexpat.so.0.5.0 8 /usr/compat/linux/usr/lib/gconv/UTF-16.so 8 /usr/compat/linux/usr/X11R6/lib/libXv.so.1.0 8 /usr/compat/linux/usr/X11R6/lib/libXss.so.1.0 8 /usr/compat/linux/usr/X11R6/lib/libXrender.so.1.2.2 8 /usr/compat/linux/usr/X11R6/lib/libXrandr.so.2.0 8 /usr/compat/linux/usr/X11R6/lib/libXinerama.so.1.0 8 /usr/compat/linux/usr/X11R6/lib/libXi.so.6.0 8 /usr/compat/linux/usr/X11R6/lib/libXfixes.so.3.0 8 /usr/compat/linux/usr/X11R6/lib/libXext.so.6.4 8 /usr/compat/linux/usr/X11R6/lib/libXcursor.so.1.0.2 8 /usr/compat/linux/usr/X11R6/lib/libX11.so.6.2 8 /usr/compat/linux/usr/X11R6/lib/libSM.so.6.0 8 /usr/compat/linux/usr/X11R6/lib/libICE.so.6.3 8 /usr/compat/linux/usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2 8 /usr/compat/linux/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 8 /usr/compat/linux/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 8 /usr/compat/linux/lib/libz.so.1.2.3 8 /usr/compat/linux/lib/librt-2.7.so 8 /usr/compat/linux/lib/libresolv-2.7.so 8 /usr/compat/linux/lib/libpthread-2.7.so 8 /usr/compat/linux/lib/libnss_files-2.7.so 8 /usr/compat/linux/lib/libnss_dns-2.7.so 8 /usr/compat/linux/lib/libm-2.7.so 8 /usr/compat/linux/lib/libgcc_s-4.1.2-20070925.so.1 8 /usr/compat/linux/lib/libdl-2.7.so 8 /usr/compat/linux/lib/libc-2.7.so 8 /usr/compat/linux/lib/libasound.so.2.0.0 8 /usr/compat/linux/lib/ld-2.7.so 8 /usr 8 /dev/null 8 / 1 /usr/local/share/applications/skype.desktop $ lsof | fgrep skype | awk ' ($9 == "") { print $5; }' | sort | uniq -c 64 PIPE 24 unix $ Looks like everything goes as expected - linux's clone() makes copy of all file-handlers per thread. So we have about ~90 (handlers per thread) * 8 (threads) = ~700 open file-handlers. Need to check, but I think, same picture should be on Linux. MacOS contrary, should have better thread support. Probably, somebody encourages skype.com to build native FreeBSD version of skype ? -- Vladimir B. Grebenschikov Parallels Inc. vova@parallels.com
On Fri, Oct 03, 2008 at 06:50:05AM +0000, Vladimir Grebenschikov wrote: > I can confirm - skype does not leak descriptors after first call. So does this mean this PR can be closed? mcl
On Fri, 2008-10-03 at 09:38 -0500, Mark Linimon wrote: > On Fri, Oct 03, 2008 at 06:50:05AM +0000, Vladimir Grebenschikov wrote: > > I can confirm - skype does not leak descriptors after first call. > > So does this mean this PR can be closed? I think - yes, but I am not reporter. > mcl -- Vladimir B. Grebenschikov Parallels Inc. vova@parallels.com
as reported by Marcin Cieslak and Vladimir Grebenschikov this PR was fixed in 1.138.2.1. linux binaries no longer leak descriptors. here's an example from running unreal tournament 2004. `while sleep 3; do lsof|grep ut2004|wc; done` reports: 0 0 0 28 247 2935 134 1201 15701 171 1534 20261 189 1697 23146 603 5523 74247 603 5523 74247 603 5523 74247 603 5523 74247 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 609 5577 74982 99 930 10920 0 0 0 cheers. alex
State Changed From-To: open->closed From the audit trail, it looks like this is now resolved.