https://bugzilla.suse.com/show_bug.cgi?id=1208188 https://bugzilla.suse.com/show_bug.cgi?id=1208188#c7 Jiri Slaby <jslaby@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?, | |needinfo?(schwab@suse.de) --- Comment #7 from Jiri Slaby <jslaby@suse.com> --- 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).

-- You are receiving this mail because: You are on the CC list for the bug.