136313 2014-08-27 14:47:28 -0700 ASSERTION FAILED: from.isCell() && from.asCell()->JSCell::inherits(std::remove_pointer<To>::type::info()) in JSC::jsCast(JSC::JSValue) [with To = JSC::JSScope*] 2014-08-27 18:07:36 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 1 akiss webkit-unassigned commit-queue gyuyoung.kim msaboff ossy zan oldest_to_newest 1031788 0 akiss 2014-08-27 14:47:28 -0700 When running tests on EFL/ARM64 (compiled with gcc), jsc segfaults on scripts containing eval() with "ASSERTION FAILED: from.isCell() && from.asCell()->JSCell::inherits(std::remove_pointer<To>::type::info())". The simplest test case to cause the assertion is: var c = ""; eval(c); The backtrace is always as follows: Program received signal SIGSEGV, Segmentation fault. 0x0000000001098298 in WTFCrash () at /home/akiss/devel/WebKit/Source/WTF/wtf/Assertions.cpp:329 329 *(int *)(uintptr_t)0xbbadbeef = 0; (gdb) bt #0 0x0000000001098298 in WTFCrash () at /home/akiss/devel/WebKit/Source/WTF/wtf/Assertions.cpp:329 #1 0x0000000000aed314 in JSC::jsCast<JSC::JSScope*> (from=...) at /home/akiss/devel/WebKit/Source/JavaScriptCore/runtime/JSCell.h:241 #2 0x0000000000ae8270 in JSC::Register::scope (this=0x7fffffe598) at /home/akiss/devel/WebKit/Source/JavaScriptCore/runtime/JSScope.h:236 #3 0x0000000000ae3d38 in JSC::ExecState::scope (this=0x7fffffe580) at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/CallFrame.h:50 #4 0x0000000000bdd8dc in JSC::eval (callFrame=0x7fffffe550) at /home/akiss/devel/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:108 #5 0x0000000000c24fbc in JSC::operationCallEval (exec=0x7fffffe5a0, execCallee=0x7fffffe550) at /home/akiss/devel/WebKit/Source/JavaScriptCore/jit/JITOperations.cpp:619 #6 0x0000007fb4ca3cec in ?? () #7 0x0000007fb43ff970 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) It seems that for JSC:eval the callFrame parameter is not set up properly: its CallerFrameAndPC component is not filled in. A little bit of analysis follows. The bytecode for the script is: [ 0] enter [ 1] mov loc0, Undefined(@k0) [ 4] resolve_scope loc1, c(@id0), 1<ThrowIfNotFound|GlobalVar>, 0 [ 10] put_to_scope loc1, c(@id0), String (atomic) (identifier): , ID: 5(@k1), 65537<DoNotThrowIfNotFound|GlobalVar>, <structure>, 26182392 [ 17] resolve_scope loc3, eval(@id1), 0<ThrowIfNotFound|GlobalProperty>, 0 [ 23] get_from_scope loc1, loc3, eval(@id1), 0<ThrowIfNotFound|GlobalProperty>, <structure>, 120 [ 31] resolve_scope loc2, c(@id0), 1<ThrowIfNotFound|GlobalVar>, 0 [ 37] get_from_scope loc2, loc2, c(@id0), 1<ThrowIfNotFound|GlobalVar>, <structure>, 26182392 [ 45] call_eval loc0, loc1, 2, 10 Original; predicting None [ 54] end loc0 The relevant JIT code compiled for the script: [ 45] call_eval loc0, loc1, 2, 10 Original; predicting None 0x7fb4ca3ca4: sub sp, fp, #64 // fp already points to the current ExecState, this will be exec for operationCallEval; start making space for execCallee on the stack (however, sp does *not* point to execCallee but to &(execCallee + JSStack::CallerFrameAndPCSize) ) 0x7fb4ca3ca8: mov w16, #0x2 0x7fb4ca3cac: stur w16, [sp, #24] // execCallee[JSStack::ArgumentCount] = 2 0x7fb4ca3cb0: movk w16, #45 0x7fb4ca3cb4: stur w16, [fp, #44] 0x7fb4ca3cb8: ldur x0, [fp, #-16] 0x7fb4ca3cbc: stur x0, [sp, #16] // execCallee[JSStack::Callee] = loc1 0x7fb4ca3cc0: sub x1, sp, #16 // now, x1 *does* point to the right place, i.e., to execCallee 0x7fb4ca3cc4: mov x0, fp // x0 points to exec 0x7fb4ca3cc8: movk w16, #46 0x7fb4ca3ccc: stur w16, [fp, #44] 0x7fb4ca3cd0: movz x17, #55504 0x7fb4ca3cd4: movk x17, #397, lsl #16 0x7fb4ca3cd8: str fp, [x17, xzr] 0x7fb4ca3cdc: movz x16, #20176 // 20176 = 0x4ed0 0x7fb4ca3ce0: movk x16, #194, lsl #16 // 194 = 0xc2 0x7fb4ca3ce4: movk x16, #0, lsl #32 0x7fb4ca3ce8: blr x16 // call JSC::operationCallEval (exec=x0, execCallee=x1) Then, in operationCallEval: EncodedJSValue JIT_OPERATION operationCallEval(ExecState* exec, ExecState* execCallee) { // ... execCallee->setScope(exec->scope()); execCallee->setCodeBlock(0); // ... JSValue result = eval(execCallee); So, the rest of execCallee is set up "below sp", but CallerFrameAndPC is *not*, because the call to operationCallEval and its prologue is expected to put the return address on top of sp, and the caller frame on top of that, thus making execCallee complete. However, the prologue does not behave as expected (at least on ARM/EFL, and compiled with gcc). The disassembled code starts with: Dump of assembler code for function JSC::operationCallEval(JSC::ExecState*, JSC::ExecState*): 0x0000000000c24ed0 <+0>: stp x29, x30, [sp,#-64]! 0x0000000000c24ed4 <+4>: mov x29, sp 0x0000000000c24ed8 <+8>: str x0, [x29,#24] 0x0000000000c24edc <+12>: str x1, [x29,#16] 0x0000000000c24ee0 <+16>: ldr x0, [x29,#24] That is, sp is "hoisted too much" in one step, making space for fp/x29 (the pointer to caller frame) and lr/x30 (the return address), which is good, and for whatever temporary space is needed (which is bad). "stp fp, lr, [sp, #-16]!" would be the expected first step here, it seems. However, this is in the hands of the compiler... Fortunately, the first parameter of operationCallEval, exec, points to the frame we need, so adding "execCallee->setCallerFrame(static_cast<CallFrame*>(exec));" to operationCallEval might solve the problem. (If I'm right.) The return address is still not set by this approach, however. This issue seems to be related to https://bugs.webkit.org/show_bug.cgi?id=127777 , which is fixed (with workaround) in https://bugs.webkit.org/show_bug.cgi?id=127898 and in https://bugs.webkit.org/show_bug.cgi?id=127909 , by passing -fno-omit-frame-pointer to gcc. 1031793 1 237257 akiss 2014-08-27 14:53:12 -0700 Created attachment 237257 Proposed patch. Since the proposed patch is not ARM64/EFL/GCC-specific, I tested it on x86_64 as well (but still on EFL and with GCC only). On ARM64, that assertion did not occur anymore when running run-javascriptcore-tests. On x86_64, all jsc tests ran correctly before and after applying the patch, both in debug and release builds. 1031801 2 msaboff 2014-08-27 15:14:33 -0700 If you build with -fno-omit-frame-pointer everywhere, does the crash still happen? 1031806 3 ossy 2014-08-27 15:19:16 -0700 (In reply to comment #2) > If you build with -fno-omit-frame-pointer everywhere, does the crash still happen? EFL builds with -fno-omit-frame-pointer long time ago ( since http://trac.webkit.org/changeset/163080 ), so the answer must be yes. 1031808 4 237257 msaboff 2014-08-27 15:25:57 -0700 Comment on attachment 237257 Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=237257&action=review r=me > Source/JavaScriptCore/jit/JITOperations.cpp:614 > + execCallee->setCallerFrame(static_cast<CallFrame*>(exec)); The static_cast is not needed. CallFrame is a typedef of ExecState. 1031823 5 237266 akiss 2014-08-27 15:52:39 -0700 Created attachment 237266 Proposed patch, v2 Static cast removed 1031825 6 237266 msaboff 2014-08-27 15:53:38 -0700 Comment on attachment 237266 Proposed patch, v2 r=me 1031832 7 237266 commit-queue 2014-08-27 16:06:17 -0700 Comment on attachment 237266 Proposed patch, v2 Clearing flags on attachment: 237266 Committed r173031: <http://trac.webkit.org/changeset/173031> 1031833 8 commit-queue 2014-08-27 16:06:21 -0700 All reviewed patches have been landed. Closing bug. 1031867 9 akiss 2014-08-27 18:07:36 -0700 For the records: On ARM64/iOS/clang, the prologue of JavaScriptCore`operationCallEval starts like this: JavaScriptCore[0x256a0c]: stp x20, x19, [sp, #-32]! JavaScriptCore[0x256a10]: stp fp, lr, [sp, #16] JavaScriptCore[0x256a14]: add fp, sp, #16 The procedure call standard for ARM64 (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf) says, in Section 5.4.3, that the location of the frame record within a stack frame is not specified, so both the iOS/clang and EFL/gcc prologues seem to be valid. 237257 2014-08-27 14:53:12 -0700 2014-08-27 15:52:39 -0700 Proposed patch. arm64-jsc-eval-segfault.patch text/plain 1430 akiss ZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvQ2hhbmdlTG9nCmluZGV4IGUyZWNlMmYuLmQ0ZTA0MzYgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL0phdmFTY3JpcHRD b3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1IEBACisyMDE0LTA4LTI3ICBBa29zIEtpc3MgIDxh a2lzc0BpbmYudS1zemVnZWQuaHU+CisKKyAgICAgICAgRW5zdXJlIHRoYXQgdGhlIGNhbGwgZnJh bWUgcGFzc2VkIGZyb20gSklUIGNvZGUgdmlhIEpTQzo6b3BlcmF0aW9uQ2FsbEV2YWwgdG8gSlND OjpldmFsIGFsd2F5cyBjb250YWlucyB0aGUgdmFsaWQgc2NvcGUgY2hhaW4uCisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xMzYzMTMKKworICAgICAgICBS ZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBEbyBub3QgcmVseSBvbiBjYWxs aW5nIGNvbnZlbnRpb25zIHRvIGZpbGwgaW4gdGhlIENhbGxlckZyYW1lIGNvbXBvbmVudAorICAg ICAgICBvZiB0aGUgZXhlY0NhbGxlZSBwYXJhbWV0ZXIgb2YgSlNDOjpvcGVyYXRpb25DYWxsRXZh bC4KKworICAgICAgICAqIGppdC9KSVRPcGVyYXRpb25zLmNwcDoKKwogMjAxNC0wOC0yNiAgTWlj aGFlbCBTYWJvZmYgIDxtc2Fib2ZmQGFwcGxlLmNvbT4KIAogICAgICAgICBSRUdSRVNTSU9OKHIx NzI3OTQpICsgMzJCaXQgYnVpbGQ6IGZvci1pbi1iYXNlLXJlYXNzaWduZWQtbGF0ZXItYW5kLWNo YW5nZS1zdHJ1Y3R1cmUuanMgZmFpbCB3aXRoIE5hTiByZXN1bHQKZGlmZiAtLWdpdCBhL1NvdXJj ZS9KYXZhU2NyaXB0Q29yZS9qaXQvSklUT3BlcmF0aW9ucy5jcHAgYi9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvaml0L0pJVE9wZXJhdGlvbnMuY3BwCmluZGV4IDY4MGRkZGUuLjNjZjgyMGIgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQvSklUT3BlcmF0aW9ucy5jcHAKKysrIGIv U291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9KSVRPcGVyYXRpb25zLmNwcApAQCAtNjExLDYgKzYx MSw3IEBAIEVuY29kZWRKU1ZhbHVlIEpJVF9PUEVSQVRJT04gb3BlcmF0aW9uQ2FsbEV2YWwoRXhl Y1N0YXRlKiBleGVjLCBFeGVjU3RhdGUqIGV4ZWNDCiAKICAgICBleGVjQ2FsbGVlLT5zZXRTY29w ZShleGVjLT5zY29wZSgpKTsKICAgICBleGVjQ2FsbGVlLT5zZXRDb2RlQmxvY2soMCk7CisgICAg ZXhlY0NhbGxlZS0+c2V0Q2FsbGVyRnJhbWUoc3RhdGljX2Nhc3Q8Q2FsbEZyYW1lKj4oZXhlYykp OwogCiAgICAgaWYgKCFpc0hvc3RGdW5jdGlvbihleGVjQ2FsbGVlLT5jYWxsZWVBc1ZhbHVlKCks IGdsb2JhbEZ1bmNFdmFsKSkKICAgICAgICAgcmV0dXJuIEpTVmFsdWU6OmVuY29kZShKU1ZhbHVl KCkpOwo= 237266 2014-08-27 15:52:39 -0700 2014-08-27 16:06:17 -0700 Proposed patch, v2 arm64-jsc-eval-segfault-v2.patch text/plain 1405 akiss ZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvSmF2 YVNjcmlwdENvcmUvQ2hhbmdlTG9nCmluZGV4IGUyZWNlMmYuLmQ0ZTA0MzYgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL0phdmFTY3JpcHRD b3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE1IEBACisyMDE0LTA4LTI3ICBBa29zIEtpc3MgIDxh a2lzc0BpbmYudS1zemVnZWQuaHU+CisKKyAgICAgICAgRW5zdXJlIHRoYXQgdGhlIGNhbGwgZnJh bWUgcGFzc2VkIGZyb20gSklUIGNvZGUgdmlhIEpTQzo6b3BlcmF0aW9uQ2FsbEV2YWwgdG8gSlND OjpldmFsIGFsd2F5cyBjb250YWlucyB0aGUgdmFsaWQgc2NvcGUgY2hhaW4uCisgICAgICAgIGh0 dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xMzYzMTMKKworICAgICAgICBS ZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBEbyBub3QgcmVseSBvbiBjYWxs aW5nIGNvbnZlbnRpb25zIHRvIGZpbGwgaW4gdGhlIENhbGxlckZyYW1lIGNvbXBvbmVudAorICAg ICAgICBvZiB0aGUgZXhlY0NhbGxlZSBwYXJhbWV0ZXIgb2YgSlNDOjpvcGVyYXRpb25DYWxsRXZh bC4KKworICAgICAgICAqIGppdC9KSVRPcGVyYXRpb25zLmNwcDoKKwogMjAxNC0wOC0yNiAgTWlj aGFlbCBTYWJvZmYgIDxtc2Fib2ZmQGFwcGxlLmNvbT4KIAogICAgICAgICBSRUdSRVNTSU9OKHIx NzI3OTQpICsgMzJCaXQgYnVpbGQ6IGZvci1pbi1iYXNlLXJlYXNzaWduZWQtbGF0ZXItYW5kLWNo YW5nZS1zdHJ1Y3R1cmUuanMgZmFpbCB3aXRoIE5hTiByZXN1bHQKZGlmZiAtLWdpdCBhL1NvdXJj ZS9KYXZhU2NyaXB0Q29yZS9qaXQvSklUT3BlcmF0aW9ucy5jcHAgYi9Tb3VyY2UvSmF2YVNjcmlw dENvcmUvaml0L0pJVE9wZXJhdGlvbnMuY3BwCmluZGV4IDY4MGRkZGUuLjJiN2Y0MGQgMTAwNjQ0 Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9qaXQvSklUT3BlcmF0aW9ucy5jcHAKKysrIGIv U291cmNlL0phdmFTY3JpcHRDb3JlL2ppdC9KSVRPcGVyYXRpb25zLmNwcApAQCAtNjExLDYgKzYx MSw3IEBAIEVuY29kZWRKU1ZhbHVlIEpJVF9PUEVSQVRJT04gb3BlcmF0aW9uQ2FsbEV2YWwoRXhl Y1N0YXRlKiBleGVjLCBFeGVjU3RhdGUqIGV4ZWNDCiAKICAgICBleGVjQ2FsbGVlLT5zZXRTY29w ZShleGVjLT5zY29wZSgpKTsKICAgICBleGVjQ2FsbGVlLT5zZXRDb2RlQmxvY2soMCk7CisgICAg ZXhlY0NhbGxlZS0+c2V0Q2FsbGVyRnJhbWUoZXhlYyk7CiAKICAgICBpZiAoIWlzSG9zdEZ1bmN0 aW9uKGV4ZWNDYWxsZWUtPmNhbGxlZUFzVmFsdWUoKSwgZ2xvYmFsRnVuY0V2YWwpKQogICAgICAg ICByZXR1cm4gSlNWYWx1ZTo6ZW5jb2RlKEpTVmFsdWUoKSk7Cg==