Bugzilla – Bug 4762
slimtray.exe doesn't release file handles
Last modified: 2007-05-17 08:00:44 UTC
i have had issues with the slimtray.exe sometimes the memory usage is too much, but in this case, it seems it is not releasing file handles. right now, it has 315,693 handles open, and steadily growing every few seconds. using XP task mngr to see the info. more info here: http://forums.slimdevices.com/showthread.php?t=32257
It's leaking process handles, not file handles. Attach to a running instance of slimtray.exe and put a breakpoint on kernel32!OpenProcess to get the callstack. There are no matching calls to CloseHandle, hence the leak.
More information: the leak is occur in response to a WM_TIMER message being sent to SlimTray. Here is the stack trace: :000> kb ChildEBP RetAddr Args to Child 0012df8c 00fe12e8 00000410 00000000 00000000 kernel32!OpenProcess WARNING: Stack unwind information not available. Following frames may be wrong. 0012fafc 28040019 0094772c 01191020 00000000 b2a837fc2c2075a59c3a5f10a2763335+0x12e8 0012fb38 2805d49d 0194772c 0094772c 280246cf perl58!Perl_sv_compile_2op+0x7b9f 0012fc0c 00402b6d 0094772c 00cac79c 00000006 perl58!Perl_runops_standard+0xc 0012fcac 00402fa1 0041121c 00000003 00000000 SlimTray+0x2b6d 0012fccc 77d48734 003e11f8 00000113 00000000 SlimTray+0x2fa1 0012fcf8 77d48816 00402def 003e11f8 00000113 USER32!InternalCallWinProc+0x28 0012fd60 77d489cd 00000000 00402def 003e11f8 USER32!UserCallWinProcCheckWow+0x150 0012fdc0 77d496c7 0012feec 00000001 0012ff4c USER32!DispatchMessageWorker+0x306 0012fdd0 00403264 0012feec 00390035 00370035 USER32!DispatchMessageA+0xf 0012ff4c 0040a297 00000001 00943ed0 00942b70 SlimTray+0x3264 0012ffc0 7c816fd7 00390035 00370035 7ffde000 SlimTray+0xa297 0012fff0 00000000 0040a1b4 00000000 78746341 kernel32!BaseProcessStart+0x23
I can see on my system that slimtray has a fairly astronomical number of handles (19,725), but I don't see them going up regularly as you describe. Is there some option or menu that seems to cause the incrementing?
mine seemed to go up no matter what. i'm surprised yours stopped. in any case, bpa wrote a patch. you can see it in the forums at the link i put in the first post.
Chris, Handles go up every 10 secs by the number of processes in your systems. I put slimsererv 6.5.2 on a clean Windows and set it up not to start. When slimtray was sitting idle and without any menu been used, the number of handles went up. The Sysinternals Process Explorer tool is good to see this and the SysInternals Handles tools allows you to see that they are process handles being accummulated. Although I found a bug with Win32::Process::List it may not be the cause of the leak with SlimTray. I rebuilt SlimTray with latest ActiveState build (820) and made some changes and the problem went away. The SlimTray that came with 6.5.2 was built with build 819 and possibly Win32::Process::List 0.1 - it looks like you should move to 820 and Win32::Process::List 0.6. Since I set up the build environment I decided to tackle a few of the bugs/behaviour 1. Handle leak - this bug 2. Stopping mysqld which is always started as a servince in 6.5 but it doesn't stop when Slimserver is stopped. This is fixed in 7.0 but in the meantime I am putting in a change toi SLimtray to stop mySqld (bug 4706) 3. SlimTray does not modify "Slimserver Web interface.url" when httpport has been changed from 9000. 4. IE windows doesn't always find Slimserver when starting up from SlimTray. 5. Bug in checkHTTP which doesn't check properly if httpport is not 9000. When I've tested the changes tonight I'll post the zip file to be reviewed and my changes accepted or rejected as you see fit.
Assigning to Dan (and cc'ing Andy) to review the changes.
Created attachment 1824 [details] Patch file to SlimTray.pl in 6.5. This file has parches to fix a number of issues with SlimTray.pl 1. Process handles leak - seem to be fixed by using Win32::Process::List 0.6 and build 820 of ActiveState. 2. Kill MySqlD.exe as well as Slim.exe when stopping Slimsever 3. Problem with checkforHTTP socket code - didn't work properly and IE window opened before Slimserver port was open. 4. Make sure IE window is opened to httpport value in Prefs file. I'm not sure whether this is just my system but "Balloons" seem to hang around much longer than timeout.
works great for me... opens to albums in fishbone skin. closes mysqld on exit. no leaky handles. how long is the balloon timeout supposed to be? (i think xp does that a lot)
Curious observation. I'm trying to sort out a socketwrapper issue but I couldn't get DEBUGPIPE debug output when running 6.5.2 so I installed 6.5.0. I now get debug output and also SlimTray doesn't leak handles AND it is only 5.8Mbytes in size. So it looks like the memory leak has something to do with build option in 6.5.1 onwards. I know some changes were made due to uneanted opening of DOS /CMD boxes when Slim.exe was a process.
Fixed in change 11647
bpa, i'm not sure what you are driving at in your curious observation, other than to say the bug seemed to be introduced in 6.5.1 but for me, slimtray is always around 14megs, and holds steady. occassionally in the past, it would somehow leak and grow, but i haven't noticed it doing that since your fix. 14megs is a lot for a pgm that doesn't do much at all. so is 5megs for that matter, but i'd take 5 if i could get it. so are you saying command line options have something to do with it?