120007 2013-08-19 05:49:30 -0700 [sh4] ASSERTION FAILED in JIT 2013-10-07 09:58:10 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 0 yannick.poirier webkit-unassigned commit-queue jbriance oldest_to_newest 918619 0 yannick.poirier 2013-08-19 05:49:30 -0700 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. 918796 1 jbriance 2013-08-19 14:37:41 -0700 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. 918963 2 yannick.poirier 2013-08-20 01:10:24 -0700 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 919013 3 jbriance 2013-08-20 05:25:15 -0700 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. 919427 4 jbriance 2013-08-21 08:47:00 -0700 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 919754 5 yannick.poirier 2013-08-22 01:11:20 -0700 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(); } 919755 6 jbriance 2013-08-22 01:19:55 -0700 (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. 921894 7 jbriance 2013-08-28 02:40:43 -0700 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? 922354 8 yannick.poirier 2013-08-29 00:49:36 -0700 (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 :) 935402 9 yannick.poirier 2013-10-02 06:42:16 -0700 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. 935405 10 jbriance 2013-10-02 08:18:17 -0700 (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. 935726 11 yannick.poirier 2013-10-02 23:56:46 -0700 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. 935840 12 jbriance 2013-10-03 10:16:14 -0700 (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 :/ 936206 13 yannick.poirier 2013-10-04 08:52:18 -0700 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 937023 14 213577 jbriance 2013-10-07 04:59:33 -0700 Created attachment 213577 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 ? 937056 15 yannick.poirier 2013-10-07 08:26:56 -0700 I've tested the patch, I confirm that it solves the ASSERT. 937082 16 jbriance 2013-10-07 09:08:14 -0700 (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). 937107 17 213577 commit-queue 2013-10-07 09:58:07 -0700 Comment on attachment 213577 Jump over maxJumpReplacementSize in revertJumpToMove implementation for sh4. Clearing flags on attachment: 213577 Committed r157046: <http://trac.webkit.org/changeset/157046> 937108 18 commit-queue 2013-10-07 09:58:10 -0700 All reviewed patches have been landed. Closing bug. 213577 2013-10-07 04:59:33 -0700 2013-10-07 09:58:07 -0700 Jump over maxJumpReplacementSize in revertJumpToMove implementation for sh4. bug-120007.patch text/plain 1870 jbriance SW5kZXg6IFNvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291 cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkocmV2aXNpb24gMTU3MDMyKQorKysgU291cmNl L0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE2IEBA CisyMDEzLTEwLTA3ICBKdWxpZW4gQnJpYW5jZWF1ICA8amJyaWFuY2VAY2lzY28uY29tPgorCisg ICAgICAgIFtzaDRdIEp1bXAgb3ZlciBtYXhKdW1wUmVwbGFjZW1lbnRTaXplIGluIHJldmVydEp1 bXBUb01vdmUuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9p ZD0xMjAwMDcKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAg ICBKdW1wIG92ZXIgbWF4SnVtcFJlcGxhY2VtZW50U2l6ZSBpbiByZXZlcnRKdW1wVG9Nb3ZlLCBl dmVuIGlmIHRoZXJlIGlzIG5vIGNvbnN0YW50CisgICAgICAgIHZhbHVlIHdpdGhpbiB0aGUgYXJl YS4gVGhpcyBwYXRjaCBmaXhlcyBkZWJ1ZyBBU1NFUlRzIGZhaWx1cmVzIGZvciBzaDQgYXJjaGl0 ZWN0dXJlLgorCisgICAgICAgICogYXNzZW1ibGVyL1NINEFzc2VtYmxlci5oOgorICAgICAgICAo SlNDOjpTSDRBc3NlbWJsZXI6OnJldmVydEp1bXBUb01vdmUpOgorCiAyMDEzLTEwLTA2ICBGaWxp cCBQaXpsbyAgPGZwaXpsb0BhcHBsZS5jb20+CiAKICAgICAgICAgVW5pZmllZCB0ZXN0IGluZnJh c3RydWN0dXJlIHZpYSB0aGUganNjIHNoZWxsCkluZGV4OiBTb3VyY2UvSmF2YVNjcmlwdENvcmUv YXNzZW1ibGVyL1NINEFzc2VtYmxlci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIFNvdXJjZS9KYXZhU2NyaXB0 Q29yZS9hc3NlbWJsZXIvU0g0QXNzZW1ibGVyLmgJKHJldmlzaW9uIDE1NjUzMSkKKysrIFNvdXJj ZS9KYXZhU2NyaXB0Q29yZS9hc3NlbWJsZXIvU0g0QXNzZW1ibGVyLmgJKHdvcmtpbmcgY29weSkK QEAgLTE1NDUsMTcgKzE1NDUsMTEgQEAgcHVibGljOgogICAgICAgICAgICAgaW5zblswXSA9IGdl dE9wY29kZUdyb3VwMyhNT1ZMX1JFQURfT0ZGUENfT1BDT0RFLCBTSDRSZWdpc3RlcnM6OnIxMywg aW5zblswXSAmIDB4MDBmZik7CiAgICAgICAgICAgICBpbnNuWzFdID0gKGluc25bMV0gJiAweGYw MGYpIHwgKHJkIDw8IDgpIHwgKFNINFJlZ2lzdGVyczo6cjEzIDw8IDQpOwogICAgICAgICAgICAg Y2FjaGVGbHVzaChpbnNuLCAyICogc2l6ZW9mKFNINFdvcmQpKTsKLSAgICAgICAgICAgIGNoYW5n ZVBDcmVsYXRpdmVBZGRyZXNzKGluc25bMF0gJiAweDAwZmYsIGluc24sIGltbSk7Ci0gICAgICAg ICAgICByZXR1cm47Ci0gICAgICAgIH0KLQotICAgICAgICBpZiAoKGluc25bMF0gJiAweDAwZmYp ID09IDEpCisgICAgICAgIH0gZWxzZSB7CiAgICAgICAgICAgICBpbnNuWzFdID0gZ2V0T3Bjb2Rl R3JvdXA2KEJSQV9PUENPREUsIDMpOwotICAgICAgICBlbHNlCi0gICAgICAgICAgICBpbnNuWzFd ID0gTk9QX09QQ09ERTsKLQotICAgICAgICBpbnNuWzJdID0gTk9QX09QQ09ERTsKLSAgICAgICAg Y2FjaGVGbHVzaCgmaW5zblsxXSwgMiAqIHNpemVvZihTSDRXb3JkKSk7CisgICAgICAgICAgICBp bnNuWzJdID0gTk9QX09QQ09ERTsKKyAgICAgICAgICAgIGNhY2hlRmx1c2goJmluc25bMV0sIDIg KiBzaXplb2YoU0g0V29yZCkpOworICAgICAgICB9CiAKICAgICAgICAgY2hhbmdlUENyZWxhdGl2 ZUFkZHJlc3MoaW5zblswXSAmIDB4MDBmZiwgaW5zbiwgaW1tKTsKICAgICB9Cg==