Bug 120007 – [sh4] ASSERTION FAILED in JIT

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

I'm facing these assertion failure when launching peacekeeper ( http://peacekeeper.futuremark.com/ )
Webkit -r154268, sh4 JIT + DFG enabled.

ASSERTION FAILED: callee != callLinkInfo->callee.get()
webkit/Source/JavaScriptCore/jit/JITStubs.cpp(1340) : void* JSC::JITStubThunked_vm_lazyLinkClosureCall(void**)

#0  WTFCrash ()	at webkit/Source/WTF/wtf/Assertions.cpp:338
#1  0x2a2deae6 in JITStubThunked_vm_lazyLinkClosureCall	(args=0x59675918)
    at webkit/Source/JavaScriptCore/jit/JITStubs.cpp:1340
#2  0x2a2de8e8 in cti_vm_lazyLinkClosureCall ()	at webkit/Source/JavaScriptCore/jit/JITStubs.cpp:1322


ASSERTION FAILED: isUndefinedOrNull()
webkit/Source/JavaScriptCore/runtime/JSCJSValue.cpp(110) : JSC::JSObject* JSC::JSValue::synthesizePrototype(JSC::ExecState*) const

#0  WTFCrash () at /home/ypo/work/git/webkit/Source/WTF/wtf/Assertions.cpp:338
#1  0x29fbe6aa in JSC::JSValue::synthesizePrototype (this=0x596766e0, exec=0x6103e6f0)
    at webkit/Source/JavaScriptCore/runtime/JSCJSValue.cpp:110
#2  0x2a2265c8 in JSC::JSValue::get (this=0x596766e0, exec=0x6103e6f0, propertyName=..., slot=...)
    at webkit/Source/JavaScriptCore/runtime/JSCJSValueInlines.h:636
#3  0x2a2264bc in JSC::JSValue::get (this=0x596766e0, exec=0x6103e6f0, propertyName=...)
    at webkit/Source/JavaScriptCore/runtime/JSCJSValueInlines.h:625
#4  0x2a2e0286 in getByVal (callFrame=0x6103e6f0, baseValue=..., subscript=..., returnAddress=...)
    at webkit/Source/JavaScriptCore/jit/JITStubs.cpp:1556
#5  0x2a2e0814 in JITStubThunked_op_get_by_val_generic (args=0x5967676c)
    at webkit/Source/JavaScriptCore/jit/JITStubs.cpp:1616
#6  0x2a2e0750 in cti_op_get_by_val_generic () at webkit/Source/JavaScriptCore/jit/JITStubs.cpp:1605


Then peacekeeper test doesn't start anymore.

[Julien Brianceau]

Hi, I have two questions:
- what port of WebKit do you use ?
- is it better if you disable the DFG ? (through "JSC_useDFGJIT=false" environment variable for instance)

I'll try to reproduce on my sh4 board tomorrow if I have time.

Hi, 

I'm using a custom port that we are developing internally. 
It uses WebCore + cairo + JavaScriptCore 

We keep JavaScriptCore unchanged

I've tested with JSC_useDFGJIT=false
Only the second assert is happening

ASSERTION FAILED: isUndefinedOrNull()
webkit/Source/JavaScriptCore/runtime/JSCJSValue.cpp(110) : JSC::JSObject* JSC::JSValue::synthesizePrototype(JSC::ExecState*) cons

The benchmark starts properly

[Julien Brianceau]

Ok. I'm able to reproduce the ASSERT failure with legitimately-captured-argument layout test. I don't know yet if this is a false positive (like https://bugs.webkit.org/show_bug.cgi?id=119794) or not.

[Julien Brianceau]

With the Qt port and using QtTestBrowser on my sh4 board, peacekeeper is crashing with current versions of WebKit (changeset 154379), whereas it was ok when using sh4 DFG before FTL merge + sh4 DFG implementation.

Is it possible for you to test with your port using sh4 DFG with a webkit without FTL merge (i.e. before changeset r153116) ?

You can find one here: https://gitorious.org/~jbrianceau/qtwebkit/jbrianceau-qt5x2, using commit id a16ebc421255106e22f7638b9082f6aebc583f7e

revision 154379:
JSC_useDFGJIT=true I've got 2 asserts

ASSERTION FAILED: callee != callLinkInfo->callee.get()
ASSERTION FAILED: isUndefinedOrNull()

JSC_useDFGJIT=false I've got 1 assert
ASSERTION FAILED: isUndefinedOrNull()

revision 153781:
DFG_JIT was not enabled, Only 1 assert
ASSERTION FAILED: isUndefinedOrNull()

I cannot easily come back prior r153116, I don't have a merge around this revision. I cannot test QtTestBrowser on my sh4 platform as we don't support Qt environment. 

After the ASSERTION FAILED: isUndefinedOrNull(), it crashes.
For now to avoid the crash I added these 2 lines in ExeceptionHandler.cpp:87

JSString* errorDescriptionForValue(ExecState* exec, JSValue v)
{
    VM& vm = exec->vm();
    if(v.isEmpty())
        return vm.smallStrings.emptyString();
}

[Julien Brianceau]

(In reply to comment #5)
> After the ASSERTION FAILED: isUndefinedOrNull(), it crashes.
> For now to avoid the crash I added these 2 lines in ExeceptionHandler.cpp:87
> 
> JSString* errorDescriptionForValue(ExecState* exec, JSValue v)
> {
>     VM& vm = exec->vm();
>     if(v.isEmpty())
>         return vm.smallStrings.emptyString();
> }

This is a workaround but not a fix, as JSValue should not be empty here.
Please take a look at https://bugs.webkit.org/show_bug.cgi?id=119812 and https://bugs.webkit.org/show_bug.cgi?id=120080 for further information.

[Julien Brianceau]

Yannick, could you test the patch I've just submitted in https://bugs.webkit.org/show_bug.cgi?id=120080 and give your feedback please?

(In reply to comment #7)
> Yannick, could you test the patch I've just submitted in 

I've tested the patch and confirm that ASSERTION FAILED: isUndefinedOrNull() is gone on peacekeeper. Nice work :)

Any news concerning ASSERTION FAILED: callee != callLinkInfo->callee.get() when DFG is enabled ?

When DFG is enabled, webkit still unstable on sh4 platform, this assert is happening quite often.

[Julien Brianceau]

(In reply to comment #9)
> Any news concerning ASSERTION FAILED: callee != callLinkInfo->callee.get() when DFG is enabled ?
No, I didn't have time to dig into this yet. And to be honest, I'm pretty sure I won't dig into this at all: as you probably know, the Qt port is moving out, including our sh4 bot (see https://bugs.webkit.org/show_bug.cgi?id=122167 and https://bugs.webkit.org/show_bug.cgi?id=122210).

> When DFG is enabled, webkit still unstable on sh4 platform, this assert is happening quite often.
If you don't have time to investigate these unstabilities, you might want to disable the DFG_JIT for your sh4 platform then. Of course it will be slower, but you'd still have LLINT & JIT parts for sh4.

I saw the news concerning QT. I did do the match with sh4. That's a bad news for me. But I would like to take over and start investigation myself. 

I'm quite new with JavaScriptCore and don't have much experience with it. 
Can you give me advice on how to start:
It could be place where to start, JSC debug technique (specially on cross-compilation environment), documentation or everything you my think useful based on your own experience.

[Julien Brianceau]

(In reply to comment #11)
> But I would like to take over and start investigation myself. 
That's good to read :)

> I'm quite new with JavaScriptCore and don't have much experience with it. 
> Can you give me advice on how to start:
> It could be place where to start, JSC debug technique (specially on cross-compilation environment), documentation or everything you my think useful based on your own experience.
When I started working on sh4 parts of WebKit, there was no LLINT and no DFG_JIT backends for this architecture, and the baseline JIT was in a "fallow" state.
As there is no documentation about these parts of JavaScriptCore (from what I know), I try to understand it by myself and do my best to implement missing things while taking a look at what other 32-bit architectures do (mips & arm).

My debug techniques: use Tools/Scripts/run-javascriptcore-tests and Tools/Scripts/run-fast-jsc scripts (you'll need a cross-compiled perl and python available on your sh4 target), using Release and Debug builds of jsc. The most important: gdb is your friend.

I know this is not so much information, but I'm afraid I won't be able to give you more inputs :/

I've isolated the piece of code to easily reproduce the ASSERT

function fcnt() {}

for (var i = 0; i < 10; ++i) {
    var f = function(){fcnt()};
    for (var j = 0; j < 10; ++j)
    	var _av = eval("f()");
}


$> bin/jsc test.js
ASSERTION FAILED: callee != callLinkInfo->callee.get()
webkit/Source/JavaScriptCore/jit/JITStubs.cpp(1331) : void* JSC::JITStubThunked_vm_lazyLinkClosureCall(void**)

#0  0x0043d13c in WTFCrash () at webkit/Source/WTF/wtf/Assertions.cpp:346
#1  0x004fc41e in JITStubThunked_vm_lazyLinkClosureCall (args=0x7bd0a5d0)
    at webkit/Source/JavaScriptCore/jit/JITStubs.cpp:1331
#2  0x004fc220 in cti_vm_lazyLinkClosureCall () at webkit/Source/JavaScriptCore/jit/JITStubs.cpp:1313

It works if
$> bin/jsc --useDFGJIT=false test.js

Any hint would be welcomed

[Julien Brianceau]

Created attachment 213577 [details]
Jump over maxJumpReplacementSize in revertJumpToMove implementation for sh4.

Thanks for the portion of code that isolates the issue. I've been able to reproduce with my board.

This patch solves the ASSERT issue for me, could you please try it and give me your feedback ?

I've tested the patch, 
I confirm that it solves the ASSERT.

[Julien Brianceau]

(In reply to comment #15)
> I've tested the patch, 
> I confirm that it solves the ASSERT.
Thanks for your feedback, I'll submit the patch for review.

I think it would be easier to talk about details of sh4 port on IRC. I'm available in #webkit and #qtwebkit channels during office hours (Paris time).

[WebKit Commit Bot]

Comment on attachment 213577 [details]
Jump over maxJumpReplacementSize in revertJumpToMove implementation for sh4.

Clearing flags on attachment: 213577

Committed r157046: <http://trac.webkit.org/changeset/157046>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.