Created attachment 100995 [details] longer backtrace Steps to reproduce: Remove panel Add new default panel. I get a stack overflow full of: #105 0x00007fffd016dfac in QQuickLayout::geometryChanged (this=0x4865840, newGeometry=..., oldGeometry=...) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/imports/layouts/qquicklayout.cpp:793 #106 0x00007ffff56d1800 in QQuickItem::setImplicitSize (this=0x4865840, w=211, h=39) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/quick/items/qquickitem.cpp:6637 #107 0x00007fffd0170875 in QQuickGridLayoutBase::invalidate (this=0x4865840, childItem=0x4865a00) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/imports/layouts/qquicklinearlayout.cpp:429 #108 0x00007fffd0170dbc in QQuickGridLayoutBase::rearrange (this=0x4865840, size=...) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/imports/layouts/qquicklinearlayout.cpp:535 #109 0x00007fffd016dfac in QQuickLayout::geometryChanged (this=0x4865840, newGeometry=..., oldGeometry=...) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/imports/layouts/qquicklayout.cpp:793 #110 0x00007ffff56d1800 in QQuickItem::setImplicitSize (this=0x4865840, w=233, h=44) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/quick/items/qquickitem.cpp:6637 #111 0x00007fffd0170875 in QQuickGridLayoutBase::invalidate (this=0x4865840, childItem=0x4865a00) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/imports/layouts/qquicklinearlayout.cpp:429 #112 0x00007fffd0170dbc in QQuickGridLayoutBase::rearrange (this=0x4865840, size=...) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarative/src/imports/layouts/qquicklinearlayout.cpp:535 #113 0x00007fffd016dfac in QQuickLayout::geometryChanged (this=0x4865840, newGeometry=..., oldGeometry=...) at /run/media/david/15cbf614-32ad-44e8-9fdc-466f76304ed7/projects/qt5/qtdeclarat 90% sure it's the new pager. I've seen this before on an applet which set the layout hints based on the size of the item - which then forces the panel (the grid layout in the log) to get stuck in a loop. There is code that sets the nuber. rows/columns based on the size of the applet, and then that updates the rowHeight which in turn sets the applet size. As i imagine you need to have exactly the correct wrong setup to replicate it, I have 3x1desktops, on two 1920x1080 screens. The pager shows both screens. I also have: file:///opt/kde5/share/plasma/plasmoids/org.kde.plasma.pager/contents/ui/main.qml:171:5: QML Flow: Binding loop detected for property "rowHeight" which is probably related.
I was thinking binding loops are false positives because the checker isn't evaluating "vertical" and just naively checking the operand references. Anyway looks credible that this issue is the Pager ...
That's not how the binding loop detection works. It's a runtime recursion check in updating the binding, emitted if you update it from within trying to update itself. It's not a check at binding compilation time.
binding loop: start break QQmlAbstractBinding::printBindingLoopError for every frame with QQmlBinding::update() call this->expressionIdentifier() TRACE: #0 file:///opt/kde5/share/plasma/plasmoids/org.kde.plasma.pager/contents/ui/main.qml:224:42 #1 file:///opt/kde5/share/plasma/plasmoids/org.kde.plasma.pager/contents/ui/main.qml:225:44 #2 file:///opt/kde5/share/plasma/plasmoids/org.kde.plasma.pager/contents/ui/main.qml:224:42 #3 file:///opt/kde5/share/plasma/plasmoids/org.kde.plasma.pager/contents/ui/main.qml:54:19 The binding loop: - anchors.fill changes the size - this causes rowHeight to re-evaluate (a correct behaviour) - this signals it has changed (a correct behaviour) - this calls columnWidth to re-evaluate (a correct behaviour) - this signals it has changed (a correct behaviour) - this causes rowHeight to re-evaluate (a correct behaviour) - BAM, binding loop. So: 1) I was right that it *is not* a false positive, as it has actually looped 2) You are right that *it is* a false positive, as you weren't going to do anything with the new evaluation, and rowHeight would not update on the second round Though this also shows that the binding loop isn't anything to do with my original bug.
David, did we fix this?
Not sure what but it seems this has gone away.