https://bugs.kde.org/show_bug.cgi?id=465872
--- Comment #24 from Fabian Vogt <fab...@ritter-vogt.de> --- (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). Can you try a hardware watchpoint on that location before the corruption happens, i.e. `watch -l m_qmlEngine`? -- You are receiving this mail because: You are watching all bug changes.
