After http://trac.webkit.org/changeset/63348 and http://trac.webkit.org/changeset/63378 (buildfix) on Windows all javascriptcore tests crash. (and QtTestBrowser too) (We really should setup a windows tester bot asap) Any idea how to fix it? I try to generate a gdb crash log asap.
Created attachment 62377 [details] Speculative fix
Comment on attachment 62377 [details] Speculative fix r=speculation!
I think the problem is that JIT_STUBS is not specifying the fastcall calling convention. I've landed a speculative fix in r63947, let's see how this goes.
+ r63948!
(In reply to comment #3) > I think the problem is that JIT_STUBS is not specifying the fastcall calling convention. I've landed a speculative fix in r63947, let's see how this goes. Unfortunately it broke the build: Creating library file: t:\WindowsRelease\buildslave\qt-windows-32bit-release\build\WebKitBuild\Release\lib\libQtWebKit4.a make.exe[1]: Leaving directory `T:/WindowsRelease/buildslave/qt-windows-32bit-release/build/WebKitBuild/Release/WebCore' ..\JavaScriptCore\release/libjscore.a(JITStubs.o):JITStubs.cpp:(.text+0x21): undefined reference to `cti_vm_throw' collect2: ld returned 1 exit status make.exe[1]: *** [..\lib\QtWebKit4.dll] Error 1
r63947 and r63948 were rolled out, because they broke Qt Windows build: http://trac.webkit.org/changeset/63950
Comment on attachment 62377 [details] Speculative fix Cleared r+ from obsolete attachment
(In reply to comment #6) > r63947 and r63948 were rolled out, because they broke Qt Windows build: > http://trac.webkit.org/changeset/63950 I mean http://trac.webkit.org/changeset/63954 . Sorry.
So, the problem is that the JIT_STUB functions need to use fastcall calling conventions. But there is an extra difficulty, in that this seems to change the mangling of a symbol – when I tried making the calls use fastcall I seem to get a link error. I think the symbol seems to get mangled differently, I think the symbol may be ending up as _cti_vm_throw instead of cti_vm_throw. I've had a couple of tries at doing this blind with no success, so I think someone who is actually developing on QT/Win is going to have to try. If nobody is available to work on this then I suggest disabling the JIT for this build.
hello.js: print("Hello World!"); backtrace in debug mode (r64038): (gdb) run t:\hello.js Starting program: T:\WindowsDebug\buildslave\qt-windows-32bit-debug\build/WebKit Build\Debug\JavaScriptCore\jsc.exe t:\hello.js [New thread 1620.0x194] ASSERTION FAILED: this[RegisterFile::ScopeChain].Register::scopeChain() (..\..\..\JavaScriptCore\interpreter/CallFrame.h:45 JSC::ScopeChainNode* JSC::ExecState::scopeChain() const) Program received signal SIGSEGV, Segmentation fault. 0x0058bda2 in JSC::ExecState::scopeChain (this=0x51800a0) at ../../../JavaScriptCore/interpreter/CallFrame.h:45 45 ASSERT(this[RegisterFile::ScopeChain].Register::scopeChain()); (gdb) bt #0 0x0058bda2 in JSC::ExecState::scopeChain (this=0x51800a0) at ../../../JavaScriptCore/interpreter/CallFrame.h:45 #1 0x004869d7 in cti_op_resolve_with_base (args=0x3e94a8) at ..\..\..\JavaScriptCore\jit\JITStubs.cpp:2913 #2 0x04f501d5 in ?? () #3 0x003e94a8 in ?? () #4 0x05229fe0 in ?? () #5 0x00000002 in ?? () #6 0x00589fa5 in JSC::JITCode::operator! (this=0x610076) at ../../../JavaScriptCore/jit/JITCode.h:56 #7 0x00752254 in JSC::Profiler::s_sharedProfiler () #8 0x00610076 in JSC::PropertySlot::setValue(JSC::JSValue)::__PRETTY_FUNCTION__ () #9 0x003e890c in ?? () #10 0x0022fd58 in ?? () #11 0x005088c9 in JSC::JITCode::execute (this=0x752254, registerFile=0x3e5c48, callFrame=0x22fd83, globalData=0x22fd58, exception=0x4dd091) at ../../../JavaScriptCore/jit/JITCode.h:77 #12 0x0022fdf8 in ?? () #13 0x00752254 in JSC::Profiler::s_sharedProfiler () #14 0x003e5c48 in ?? () #15 0x0022fd83 in ?? () #16 0x0022fd58 in ?? () #17 0x004dd091 in CallRecord (this=0x0) at ../../../JavaScriptCore/bytecode/SamplingTool.h:178 #18 0x00000000 in ?? ()
This looks like expected behaviour. :-)
Created attachment 66722 [details] proposed fix Based on patches of Gavin Barraclough: r63947 and r63948. I added a new SYMBOL_STRING_RELOCATION(...) case for MinGW, because MinGW adds a "@" prefix and "@4" suffix to symbol names when you use fastcall conventions.
Comment on attachment 66722 [details] proposed fix r=me
Comment on attachment 66722 [details] proposed fix Clearing flags on attachment: 66722 Committed r67062: <http://trac.webkit.org/changeset/67062>
All reviewed patches have been landed. Closing bug.