Memory leak when viewing gifs

Tracked by Jolla

asked 2017-02-09 18:35:11 +0200

szopin gravatar image

updated 2017-04-25 23:52:00 +0200

nthn gravatar image

In quickddit when viewing a gif memory goes through the roof and kills all apps (lighthouse got killed with 97% still on the cover, from 60ish when loading)

seems to work on most, the one that misbehaves was linked as jpg, might be just quickddit bug (never seen this before, quickddit would crash sometimes, but without killing bg apps)

edit retag flag offensive close delete

Comments

This already happened before 2.1, only experienced it with Quickddit.

nthn ( 2017-02-09 18:43:28 +0200 )edit

never seen it killing all apps in the process, it would crash just quickddit, now everything got killed

szopin ( 2017-02-09 18:46:40 +0200 )edit
1

@Sage added tag 3rd party, I agree bug is in 3rd party app, but the new behaviour is in SFOS, 3rd party app crashing itself - fine, taking everything else with it, not sure if desired effect Did raise an issue on github, so if SFOS allowing mass killing of apps due to one runaway app is expected this can be closed

szopin ( 2017-02-09 21:31:13 +0200 )edit
4

No, the bug is not in Quickddit, it merely exposes the bug. As reddit is basically offering images from all over the internet, it is likely the first app that encounters a problematic image. Quickddit simply passes the URL posted on reddit to the source property of (Animated)Image. After that the app doesn't have any control over what Silica/QtQuick does internally.

A similar thing happens when images are scaled above the EGL texture limit (the infamous black screen bug). There's no texture limit exposed in a readable property, and there's no signal in AnimatedImage if it goes above a resolution supported by the backend. That's why a workaround with hardcoded (experimentally found) limits has been implemented for this bug.

Unfortunately, for 'memory ballooning' images there's no way I can make a workaround, it has to be fixed within QtQuick/Silica.

It's a bit disappointing this was marked as 3rdparty, because a crashing or memory ballooning component is an indication that there might be a security issue in the image parser, possibly leading to an exploit.

accumulator ( 2017-04-25 16:53:12 +0200 )edit

Can anyone supply a URL for an image which causes this? It sounds like it should be very reproducable with the right (wrong?) image

Andy Branson ( 2017-04-26 10:00:26 +0200 )edit