Bugzilla – Bug 4496
Memory leak causes slim.exe service to crash every day or two
Last modified: 2011-03-16 04:45:50 UTC
SlimServer Version: 6.5.0 - 9916 - Windows NT4 - EN - cp1252 Server IP address: 192.168.69.25 Perl Version: 5.8.7 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt Our slimserver continues to consume memory constantly, until eventually the machine runs out and the slim.exe process crashes and has to be restarted. Typically the playlist is all of around 6,500 MP3 tracks in random mode and are being played by a single client (Turtle Beach Audiotron) that is listening to http://<server>/stream.mp3 Typically one or two web-browsers are also open on the slim server front page from other client PCs. Using performance monitor over an 8min 20sec period I noted the memory go from 215,486,464 bytes to 217,116,672 (high numbers as the slim.exe has been running for nearly a day now), i.e. a climb of 1,630,208 bytes. It seems as if each time a new track starts the memory used from the previous track is not freed up.
Created attachment 1697 [details] Screen capture of Performance Monitor monitoring slim.exe This is a screen capture of performance monitor tracking working set of the slim.exe process (remotely). Note, the period of the graph is 8m20s.
As instructed on the bugzilla main page, please try the latest stable nightly build.
OK, updated to nightly build of 6.5.1 SlimServer Version: 6.5.1 - 10638 - Windows NT4 - EN - cp1252 Server IP address: 0.0.0.0 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt We are still seeing the continual memory increase. Over a 50 minute period the working set has moved from 108,769,280 bytes to 112,070,656 bytes, i.e. and increase of 3,301,376. At this point slim.exe has been running for an hour or two.
145,018,880 bytes now, and still climbing steadily.
does it stop climbing if your client is not connected, if you stop streaming or if you leave the web interfaces closed?
The client has been disconnected now for a few hours, the trend has continue to increase at the same rate. I'll now stop the stream.
Pressed STOP on playlist last night. The memory leak has continued, although possibly at a very slightly slower rate.
We had two clients connected showing the PDA skin and one CLI client subscribed to track change notifications. We disconnect all of these so that no clients were hitting the slim.exe webserver and the leak stopped. I reconnect clients (4, using Firefox) to the http://<server>:9000 and immediately the leak began again. I stopped these clients and started the CLI client http://<server>:9090 and the memory use seems stable again. So it looks like its the HTTP clients that cause the leak. Note, the clients are not running on the same node as the server.
Update. Slim.exe has been running for several days now. My trend of Virtual Bytes and Working Set are pretty much level (well VB is completely flat, Working Set might have gained 200k, but does go down on some occasions). I've been able to achieve this by not connecting any web browsers to the web interface on http://<server>:9000. The moment I connect a client the memory usage starts to go up (and not come back down again). Obviously this makes playlist management a bit tricky.
So cli connection is ok, but I'm still not following you on the "clients". Having a browser open showing the slimserver page w/ pda skin is causing memory use to grow? connecting to stream.mp3 and sitting idle grows? playing something on stream.mp3 grows? focussing on the browsing, what about sticking with one browser and use the default or light skins for testing (http://<serverip>:9000/Default/ or http://<serverip>:9000/EN/
OK. slim.exe memory use is rock steady until a browser connects to http://<server>:9000 or http://<server>:9000/pda, at which point memory usage of slim.exe ramps up. Memory usage then does NOT drop when browser clients disconnect. What was killing my slim.exe every couple of days was 2 or 3 machines which had browser windows open on the front page to watch the play queue (one user was embedding the pda skin in his active desktop background - users eh? but what can you do?) Originally I thought the problem was the streaming because I didn't think anyone would have their browsers permanently connected. Unfortunately aforementioned users are getting smart with tabbed browser windows in Firefox and clever active desktop tricks.
when you mendion http://server:9000, is that to imply the defaul skin or have you go the 'pda' skin set as the preferred skin? I'm not familiar with that skin (third party/modified Handheld skin?).
Sorry I meant the 'handheld' skin, not a 'pda' skin. I believe its one of the standard ones. I think there were possibly three clients connected permanently, 1. An iPAQ using the http://<server>/handheld skin 2. Windows XP active desktop showing http://<server>/handheld skin 3. Windows XP running Firefox showing http://<server>/ (default skin) It seems that any of these pages would cause the memory usage of slim.exe to grow (i.e. it didn't seem to be just the fault of the handheld skin, or the default skin)
For the record, I have not yet been able to reproduce this bug. What kind of tracks are you playing? Is there anything else peculiar about the system setup that I should know to accurately reproduce the issue?
Dan recently mentioned seeing a javascript memory leak in Default skin, Firefox on OSX which I have been unable to reproduce. Dan also recently upgraded the Template Toolkit version, which apparently fixes a template memory leak (also not one that I never saw). If this was a case of the template leak, then it should be fixed in the most recent builds (last 3 days or so)
Suggestion: Disable all plugins and see if SlimServer's memory usage continues to grow in the same manner. I've seen some plugins that leak badly. If it stops, re-enable them one by one until you find the culprit(s). I'm currently running just Date & Time, Random Mix and Digital Inputs (for the Transporter) and the memory usage is very steady, even with a browser always open to the web interface.
anything new here? Chris, what is the state of NT support?
We'll still support NT to the best of our ability if we can get some more info to help repro this!
Okay the state of NT support is now 'not officially supported'. Of course, many users are running OSes that aren't officially supported, so we'll do what we can. But this doesn't seem to be a widespread problem.
I'm trying to locate an NT test platform.
I'm afraid we're not going to spend any more time tracking this down. I'd be willing to hear from other users having this problem to consider re-opening.
Reduce number of active targets for SC