Bug#685524: Reopen #685524
The changelog for -3 includes "Add fix_jit_crash_on_x86_64.patch, which
avoids 32-bit branch offset overflows. Taken from upstream." This is
either the same patch that was removed in -2, or a new patch causing the
same symptoms. Here is a backtrace from lightdm-kde-greeter (I'm not
currently running kwin, but I assume it would crash the same way):
#0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:495
#1 0x00007ffff453f0cb in memcpy (__len=<optimized out>,
__src=<optimized out>, __dest=<optimized out>)
at /usr/include/x86_64-linux-gnu/bits/string3.h:52
#2 executableCopy (allocator=0x7ffff7e6e960, this=<optimized out>)
at ../3rdparty/javascriptcore/JavaScriptCore/assembler/AssemblerBuffer.h:139
#3 executableCopy (allocator=0x7ffff7e6e960, this=0x7fffffffd860)
at ../3rdparty/javascriptcore/JavaScriptCore/assembler/X86Assembler.h:1885
#4 executableCopy (allocator=0x7ffff7e6e960, this=0x7fffffffd860)
at ../3rdparty/javascriptcore/JavaScriptCore/assembler/X86Assembler.h:1583
#5 LinkBuffer (executablePool=..., masm=0x7fffffffd860, this=0x7fffffffd7d0)
at ../3rdparty/javascriptcore/JavaScriptCore/assembler/LinkBuffer.h:67
#6 QTJSC::JIT::privateCompileCTIMachineTrampolines (this=0x7fffffffd860,
executablePool=0x7ffff7e689e8, globalData=<optimized out>,
ctiStringLengthTrampoline=0x7ffff7e689f0,
ctiVirtualCallLink=0x7ffff7e689f8, ctiVirtualCall=0x7ffff7e68a00,
ctiNativeCallThunk=0x7ffff7e68a08)
at ../3rdparty/javascriptcore/JavaScriptCore/jit/JITOpcodes.cpp:1817
#7 0x00007ffff45547fc in QTJSC::JIT::compileCTIMachineTrampolines (
globalData=0x7ffff7e67800,
executablePool=executablePool@entry=0x7ffff7e689e8,
ctiStringLengthTrampoline=ctiStringLengthTrampoline@entry=0x7ffff7e689f0,
ctiVirtualCallLink=ctiVirtualCallLink@entry=0x7ffff7e689f8,
ctiVirtualCall=ctiVirtualCall@entry=0x7ffff7e68a00,
ctiNativeCallThunk=ctiNativeCallThunk@entry=0x7ffff7e68a08)
at ../3rdparty/javascriptcore/JavaScriptCore/jit/JIT.h:323
#8 0x00007ffff4550cb3 in QTJSC::JITThunks::JITThunks (this=0x7ffff7e689e8,
globalData=<optimized out>)
at ../3rdparty/javascriptcore/JavaScriptCore/jit/JITStubs.cpp:768
#9 0x00007ffff459d738 in QTJSC::JSGlobalData::JSGlobalData (
this=0x7ffff7e67800, isShared=<optimized out>)
at ../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:146
#10 0x00007ffff459ddec in QTJSC::JSGlobalData::create ()
at ../3rdparty/javascriptcore/JavaScriptCore/runtime/JSGlobalData.cpp:205
#11 0x00007ffff463e380 in QScriptEnginePrivate::QScriptEnginePrivate (
this=0x7f75e0) at api/qscriptengine.cpp:979
#12 0x00007ffff463f376 in QScriptEngine::QScriptEngine (this=0x7eb3c8)
at api/qscriptengine.cpp:1964
#13 0x00007ffff79ed51c in QDeclarativeScriptEngine::QDeclarativeScriptEngine (
this=0x7eb3c8, priv=0x7eb2c0) at qml/qdeclarativeengine.cpp:382
#14 0x00007ffff79f23cf in QDeclarativeEnginePrivate::QDeclarativeEnginePrivate
(this=0x7eb2c0, e=0x7f7b50) at qml/qdeclarativeengine.cpp:353
#15 0x00007ffff79f26b1 in QDeclarativeEngine::QDeclarativeEngine (
this=0x7f7b50, parent=0x0) at qml/qdeclarativeengine.cpp:634
#16 0x00007ffff78f1746 in QDeclarativeViewPrivate::init (
this=this@entry=0x7fbe40) at util/qdeclarativeview.cpp:281
#17 0x00007ffff78f1973 in QDeclarativeView::QDeclarativeView (this=0x7f80f0,
parent=0x0) at util/qdeclarativeview.cpp:261
#18 0x000000000040b1e7 in _start ()
As previously mentioned, this may be hardware dependent. One theory was
that the amount of physical memory has something to do with this, the
machine I'm seeing this on has 1gb. Testing in a vm with limited memory
may help in reproducing.
--
Arto Jantunen
Reply to: