Bugzilla – Bug 14836
Memory leak in Surface zoom function
Last modified: 2010-04-08 17:26:51 UTC
Created attachment 6169 [details] MemLeak applet that can be used to reproduce bug There seems to be a memory leak in the zoom function. With code like this it leaks: local tmp = self:_loadImage("album.png"):zoom(zoomx,zoomy,1) tmp:blit(screen,positionx,positiony) tmp:release() With code like this it doesn't leak: local tmp = self:_loadImage("album.png") tmp:blit(screen,positionx,positiony) The problem can be reproduced with the attached applet "MemLeak", just install it, configure "Mem Leak" applet as screen saver and let it run for a 15-30 minutes or something similar and you will see that the amount if free memory is decreasing. It's not decreasing a lot, but it's enough to get out of memory in a day or two for a screen saver applet that runs continuously. I found the problem during development on the Album Flow applet which causes reboots at least once a day due to this bug. I'm not sure the problem is reproducible on a PC but it's definitely reproducible when executed on a real Squeezebox Touch device. I've tried manually calling collectgarbage() but it doesn't help, it still leaks resources. It's a problem for all applets that regularly call the Surface:zoom() function.
The attached MemLeak applet has now been running 24 hours on my Touch. The free memory has gone from 65MB to 25MB during this time, so it seems to leak approximately 40MB per 24 hours. The Touch has just been standing there with off screen saver active, I haven't played any music or done anything else with the Touch during these 24 hours.
== Auto-comment from SVN commit #7947 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7947 == Fixed Bug: 14836 +3 Description: - release() was incorrectly lowering the ref count, which caused srf to never be freed.
This doesn't work, in 7965 this leaks more than ever. Instead of surviving two days it now survives 1 minute with the attached MemLeak applet.
erland, just a wild guess ... Could it be, that the original image needs to be released too ? Like local tmp1=self:_loadImage(...) local tmp2=tmp1.zoom(...) tmp2.blit(...) tmp2.release() tmp1.release()
(In reply to comment #4) > erland, just a wild guess ... > Could it be, that the original image needs to be released too ? > > Like > > local tmp1=self:_loadImage(...) > local tmp2=tmp1.zoom(...) > tmp2.blit(...) > tmp2.release() > tmp1.release() The implementation of _loadImage returns the same instance every time, it loads it the first time and return it from the cache when called the next time. So unless I'm missing something I shouldn't have to release a image I plan to use later. zoom() needs the release() call since it returns a new image every time.
== Auto-comment from SVN commit #7986 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7986 == Bug: 14836 +3 Description: - release() ignores refcount now, null protection added
Erland, please try again with r7986.
== Auto-comment from SVN commit #7988 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7988 == Bug: 14836 Description: - release() ignores refcount now, null protection added
== Auto-comment from SVN commit #7989 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7989 == Bug: 14836 Description: - some null protections were unneeded, caused verbose output.
(In reply to comment #7) > Erland, please try again with r7986. I've now used Album Flow applet for about 8 hours on firmware 7998 and it doesn't seem to leak anymore. It would have leaked at least 10-20 MB with the 7.4 release. So I think we safely can consider this problem solved with your latest fix.
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!