Bug 42818 – [Qt] REGRESSION(63348): jsc is broken

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Csaba Osztrogonác]

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.

[Gavin Barraclough]

Created attachment 62377 [details]
Speculative fix

[Oliver Hunt]

Comment on attachment 62377 [details]
Speculative fix

r=speculation!

[Gavin Barraclough]

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.

[Gavin Barraclough]

+ r63948!

[Csaba Osztrogonác]

(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

[Csaba Osztrogonác]

r63947 and r63948 were rolled out, because they broke Qt Windows build:
http://trac.webkit.org/changeset/63950

[Csaba Osztrogonác]

Comment on attachment 62377 [details]
Speculative fix

Cleared r+ from obsolete attachment

[Csaba Osztrogonác]

(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.

[Gavin Barraclough]

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.

[Csaba Osztrogonác]

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 ?? ()

[Gavin Barraclough]

This looks like expected behaviour. :-)

[Csaba Osztrogonác]

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.

[Oliver Hunt]

Comment on attachment 66722 [details]
proposed fix

r=me

[Csaba Osztrogonác]

Comment on attachment 66722 [details]
proposed fix

Clearing flags on attachment: 66722

Committed r67062: <http://trac.webkit.org/changeset/67062>

[Csaba Osztrogonác]

All reviewed patches have been landed.  Closing bug.