Bug 16360 - Imageviewer delay >= screensaver delay = memory leak
: Imageviewer delay >= screensaver delay = memory leak
Status: UNCONFIRMED
Product: SqueezePlay
Classification: Unclassified
Component: Screensavers
: unspecified
: PC Linux (other)
: -- normal with 1 vote (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-12 17:43 UTC by Graham
Modified: 2012-08-03 13:26 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments
imageviewer/screensaver log (15.15 KB, text/plain)
2010-07-14 08:47 UTC, Michael Herger
Details
SqueezeboxTouch log (56.53 KB, text/plain)
2012-08-03 13:25 UTC, artur.w
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Graham 2010-07-12 17:43:16 UTC
Squeezeplay was causing the OOM killer to come into play on my workstation. The memory leak is caused by using the imageviewer screensaver (http source) with a delay between images that is larger than or equal to the screensaver delay. 

The screensaver restarts at each screensaver-delay interval, showing the initial "Loading" message. When this occurs it seems some memory is not freed from the previous imageviewer. Even when the screensaver is stopped, the memory is not recovered. 

The first 4 or 5 images which seem OK, then the memory usage of jive grows by about 1Mb per image (using JPEGs direct from my 8MP camera).

I'm currently seeing this on Squeezeplay 7.6 r8090.
Comment 1 Michael Herger 2010-07-14 08:47:59 UTC
Created attachment 6912 [details]
imageviewer/screensaver log

there's definitely a difference being logged between when screensaver delay <= IV delay (first part of log) and when SS delay > IV delay (second part)

You mention seeing a OOM on your _workstation_?
Comment 2 Graham 2010-07-14 09:43:49 UTC
Yes, as far as I can see the screensaver is repeatedly restarted when SS delay <= IV delay. The 'Loading' message appears and the transition effect is drawn against the normal squeezeplay background, not the previous image as you would expect. Also if, for example, SS delay = 30s and IV delay = 1m you still get a new picture every 30s as the screensaver starts again.

IMHO maybe there are 2 issues here:
1) The screensaver is 'forgetting' it is on, however when the IV delay is lower each new image resets the SS timer, so it doesn't start again. 
2) As a result of issue 1, when the screensaver restarts the previous image buffer is never released, or at least never garbage collected. 

Yes, I saw the OOM on a workstation. I don't use the imageviewer on my radio or controller, as frankly, the screens are a bit small for that. However, I have a Samsung USB mini-monitor on a PC that I use to run squeezeplay in it's own X-server for 'music while I work'. As the display is 800x480 I customised the radio skin to increase the resolution, font sizes etc. I'm not sure if this larger image size exaggerates the memory leak, but 1 day of displaying images every 3s was enough to OOM the box (4GB RAM but no SWAP as it's diskless). I did check, and the leak is still present if I run a standard skin too.

I haven't tried it on Logitech hardware, but I've no reason to believe it would behave any differently.
Comment 3 artur.w 2012-08-03 13:25:30 UTC
Created attachment 7677 [details]
SqueezeboxTouch log
Comment 4 artur.w 2012-08-03 13:26:10 UTC
Same happens on my Squeezebox Touch device with version 7.7.2r9663 as well as with current nightly build 7.8.0r16736

Log file attached ('SqueezeboxTouch log').

Having ImageViewer as ScreenSaver running in device off-state. 
By the way, the imageviewer interval times >10sec are ignored at all and stay at 10sec.

Checking with 'top' shows that jive is increasingly consuming memory until oom-killer does its job and restart the system.

Image files are located on a SD-card, having a small size, actually exactly the screen resolution with around 100 Kb file size.

The log shows that 'ScreenSaversApplet' is doing 'activating ImageViewer screensaver' for every single file. That explains also the annoying loading-icon between each picture during the slideshow and most probably this is also the reason for the memory leak.