https://bugs.kde.org/show_bug.cgi?id=465872
--- Comment #23 from Jiri Slaby <jirisl...@gmail.com> ---
(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).
--
You are receiving this mail because:
You are watching all bug changes.
