@stan.m The root cause was a thread-safety problem; data was read by the main thread at the same time that it was written by another thread. Specifically, the C++ getter for the QString "value" property was called at the same time that the value was written. Other data was written and read at the same time, but their types write as an atomic operation on the ARM processor. The data that caused the problem was of type: QString.
A QString object's member data is a heap pointer to the 16-bit unicode array. When written and read simultaneously, the C++ getter passes a corrupted pointer into the QML runtime. As I wrote before, the "binding loop" warning came after many of these "first-chance" exceptions and had nothing to do with a true binding loop.
The first-chance exception occurred when two value changes occurred back-to-back and the QML runtime called the C++ getter to retrieve the value at the same time that the second change was written.
My initial "fix" worked because polling the value every 100ms allowed the first change propagate to QML long before the next change comes in.
I since have revised the code to use a mutex to prevent writing and reading simultaneously.
Ultimately I think that you should use imperative object creation only for temporary object needed by the UI layer, like showing a dialog for example. I have yet to see another legit usecase for it (or I don't remember it).
I will keep this in mind!
Hopefully this little discusion might help someone else struggling to understand the same concepts!
@raven-worx: Yes, it's ambiguous because I don't know (or there isn't) a syntax for disambiguating. For example in C++ a roughly equivalent statement, involving a local text and a global text, would be text = ::text which is unambiguous.
Hehe, I was discussing that with others last week, a way to differentiate context properties from regular object properties. Could be used in your case to disambiguate the root context property, or to access model properties from outside a delegate, for example : listView.currentItem::age without having to expose it as a property.
This syntax is not achievable for the moment, but you could do something like this listView.currentItem.Context.property("age"), you won't get notified of any change though. You could also do it for the root context with a singleton exposing it with the same caveat about the changes.