Comment # 7 on bug 1208188 from Jiri Slaby

Andreas, due to:

(In reply to Jiri Slaby from comment #5)
> 2) it is enough to "zypper up glibc" for this to start happenning.

2.36 -> 2.37 to be more specific. Any idea why the below can happen?

Quoting from https://bugs.kde.org/show_bug.cgi?id=465872#c23:

(In reply to Jiri Slaby from comment #23)
> (In reply to Jiri Slaby from comment #22)
> > Ah, because it's not ep at that location -- 0xb706dff0 is code, not data:
> 
> So:
> ================ ExecutionEngine::setQmlEngine(this=0xb59250) sets
> m_qmlEngine to 0xb7b73c
> <no other setQmlEngine() here>
> virtualGet that=0x9fbc0820
>         eng=0xb59250
>         qeng=0xb7208f08
> 
> I.e. ExecutionEngine is created by new(), 0xb7b73c is set as m_qmlEngine.
> Nothing else sets m_qmlEngine during runtime and then it crashes. At that
> point, the engine is still the one created earlier (0xb59250), but its
> m_qmlEngine is suddenly 0xb7208f08 (a pointer to the code). This really
> looks like a memory corruption.
> 
> Note that when I set up a breakpoint in ExecutionEngine::setQmlEngine, the
> issue doesn't occur. So it is likely racy on the top of the above. (I wanted
> to add a "watch" to ExecutionEngine::m_qmlEngine there to see who overwrites
> that.
> 
> Maybe we should continue in downstream (openSUSE miscompilation) or upstream
> (qt bug).