Repeatedly loading QML file including QtGraphicalEffects' Glow (or enabling/disabling a Glow layer) eventually causing a QSGRenderThread assert fail and/or visual oddities and apparently unbounded memory consumption

For a while now I've had some suspicions about something leaking or flaky in a couple of (as yet unreleased) QML-based applications I've also tried building for iOS (so this may go back longer than 5.5.0... or maybe not; see 1st comment subsequently added) and I've finally managed to track it down to one particular thing and create a minimal demonstrator.

The code at https://bitbucket.org/timday/qmltoy/src is a simple QQuickView QML "player"; main.cpp, Browser.h and Browser.cpp should be compiled for iOS, with file-sharing enabled (MAKE-ios). The files index.qml, glowsoak.qml and butterfly.png should be copied to the app's docs (via itunes); (re)starting the app should bring up the index.qml's file browser, and then glowsoak.qml can be selected & opened...

glowsoak.qml is pretty much a copy of the Glow documentation's example, except that it will request the host QQuickView (exposed via context; see Browser.cpp) to reload the QML file every 250ms. This will be seen to crash not long after the application is started (generally once memory consumption - which creeps upwards steadily - is around 30-40MByte although it can be sooner). Visual artefacts may sometimes be seen shortly before the crash (e.g the image disappears leaving only the glow). The crash appears to be in the depths of the QSGRenderThread, due to an out of range access request on a QVector<int>::at (OK technically it's a fatal assert, not a crash).

Note that commenting out the Glow effect in glowsoak.qml (and the Image's visible: false, to make that visible) results in something that seems to be able to run indefinitely and doesn't exhibit steadily increasing memory consumption at all so far as I can see, despite continuing to repeatedly reload the QML file. So Glow seems to be misbehaving. How important its apparent memory consumption leak is I don't know: the QML engine may just not have GC-ed yet, or maybe it's a side-effect of some other problem. I doubt it's a memory exhaustion issue as the as a subsequently added videosoak.qml (see below) gets bigger without crashing.

I've not investigated whether the issue is actually present on other platforms (I also build routinely on OSX & Linux); possibly they're just more tolerant than the low-memory systems of the iOS world, if it is a leak issue, or possibly it's some timing thing exposed by low-performance iOS HW. I do use Glow quite a lot and it's only on iOS I've seen odd fails when loading new QML files (which I'm now realising probably all had some Glow in them). Nor am I (yet) a Qt source hacker; just a user, so I've not looked into any of the code where the assert fails.

I've tagged the source repo qtbug-47448 immediately after creating this issue.

(Shortly after, I added an imagesoak.qml - which is just the glowsoak.qml without the Glow - and modified an older videosoak.qml to do the same sort of thing; both will run and run for ages without issue; the imagesoak.qml reloads at 250ms and memory consumption seemed to go nowhere. But videosoak.qml reloading at 1000ms intervals - to give the video time to get started - did seem to gradually be growing memory consumption though, although not at a rate which should cause any real-world application problems (was up to 55MByte after 30mins of non-stop reloading but that may just be the QML engine hasn't bothered to GC yet for all I know).