Bug 142030

Summary:

REGRESSION(r180595): construct varargs fails in FTL

Product:

WebKit

Reporter:

Ryosuke Niwa <rniwa>

Component:

JavaScriptCore

Assignee:

Ryosuke Niwa <rniwa>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

akiss, commit-queue, ddkilzer, fpizlo, ggaren, msaboff, ossy

Priority:

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Bug Depends on:

Bug Blocks:

108645

Attachments:

Description	Flags
Fixes the bug	ggaren: review+
Fix 2	none

Ryosuke Niwa

Reported 2015-02-25 17:18:40 PST

After http://trac.webkit.org/changeset/180595, construct varargs fails in FTL with a following error: Failed to insert inline cache for varargs call (specifically, ConstructVarargs) because we thought the size would be 284 but it ended up being 300 prior to compaction.

Attachments
Fixes the bug (1.26 KB, patch) 2015-02-25 17:21 PST, Ryosuke Niwa	ggaren: review+	Details Formatted Diff Diff
Fix 2 (2.17 KB, patch) 2015-03-06 16:49 PST, Ryosuke Niwa	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Ryosuke Niwa

Comment 1 2015-02-25 17:21:04 PST

Created attachment 247371 [details] Fixes the bug

Geoffrey Garen

Comment 2 2015-02-25 17:22:23 PST

Comment on attachment 247371 [details] Fixes the bug r=me

Ryosuke Niwa

Comment 3 2015-02-25 17:24:48 PST

Committed r180651: <http://trac.webkit.org/changeset/180651>

David Kilzer (:ddkilzer)

Comment 4 2015-02-25 19:07:51 PST

Can we construct a COMPILE_ASSERT() here that will fail if we change the size of construct_varargs again?

Filip Pizlo

Comment 5 2015-02-25 19:10:14 PST

(In reply to comment #4) > Can we construct a COMPILE_ASSERT() here that will fail if we change the > size of construct_varargs again? No. The sizes of machine code snippets arise dynamically and cannot be computed at compile time. The right solution is for LLVM to give us a resizable patchpoint.

Michael Saboff

Comment 6 2015-02-26 07:54:18 PST

Looks like there is still an issue on ARM64 iOS. This is intermittent, probably due to whether or not we tier up to the FTL. Test Failures r180666 r180667 regress/script-tests/deltablue-varargs.js.ftl-eager Passed Failed [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: Failed to insert inline cache for varargs call (specifically, CallVarargs) because we thought the size would be 300 but it ended up being 332 prior to compaction. [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 1 0x100211be0 JSC::FTL::compile(JSC::FTL::State&, JSC::DFG::Safepoint::Result&) [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 2 0x1001888bc JSC::DFG::Plan::compileInThreadImpl(JSC::DFG::LongLivedState&) [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 3 0x100188004 JSC::DFG::Plan::compileInThread(JSC::DFG::LongLivedState&, JSC::DFG::ThreadData*) [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 4 0x100202ed4 JSC::DFG::Worklist::runThread(JSC::DFG::ThreadData*) [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 5 0x100527330 WTF::threadEntryPoint(void*) [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 6 0x100527778 WTF::wtfThreadEntryPoint(void*) [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 7 0x1977efe5c <redacted> [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 8 0x1977efdbc <redacted> [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: 9 0x1977ecfc4 thread_start [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: ./test_script_4260: line 2: 79433 Segmentation fault: 11 "$@" /System/Library/Frameworks/JavaScriptCore.framework/Resources/jsc --useFTLJIT\=false --enableFunctionDotArguments\=true --useFTLJIT\=true --thresholdForJITAfterWarmUp\=10 --thresholdForJITSoon\=10 --thresholdForOptimizeAfterWarmUp\=20 --thresholdForOptimizeAfterLongWarmUp\=20 --thresholdForOptimizeSoon\=20 --thresholdForFTLOptimizeAfterWarmUp\=20 --thresholdForFTLOptimizeSoon\=20 --maximumEvalCacheableSourceLength\=150000 deltablue-varargs.js [2015-02-26 06:01:59] INFO: regress/script-tests/deltablue-varargs.js.ftl-eager: ERROR: Unexpected exit code: 139 [2015-02-26 06:01:59] ERROR: FAIL: regress/script-tests/deltablue-varargs.js.ftl-eager

Csaba Osztrogonác

Comment 7 2015-03-04 03:08:04 PST

Still valid on Aarch64 Linux too: 5 test run, number of failures: 1 FAIL: regress/script-tests/deltablue-varargs.js.default-ftl 1 FAIL: regress/script-tests/deltablue-varargs.js.dfg-eager-no-cjit-validate 1 FAIL: regress/script-tests/deltablue-varargs.js.ftl-eager-no-cjit 1 FAIL: regress/script-tests/deltablue-varargs.js.ftl-no-cjit-validate 1 FAIL: regress/script-tests/deltablue-varargs.js.ftl-no-cjit-no-inline-validate 6 FAIL: regress/script-tests/deltablue-varargs.js.ftl-eager $ cat deltablue-varargs.js.ftl-eager.out Failed to insert inline cache for varargs call (specifically, CallVarargs) because we thought the size would be 300 but it ended up being 332 prior to compaction. Segmentation fault $ cat deltablue-varargs.js.ftl-no-cjit-validate.out Timed out after 240.000000 seconds! Segmentation fault

Csaba Osztrogonác

Comment 8 2015-03-04 03:34:30 PST

deltablue-varargs.js is skipped on iOS from the beggining - r180279 : //@ skip if $architecture == "arm" and $hostOS == "darwin"

Ryosuke Niwa

Comment 9 2015-03-06 16:49:26 PST

Created attachment 248114 [details] Fix 2

Michael Saboff

Comment 10 2015-03-06 16:50:20 PST

Comment on attachment 248114 [details] Fix 2 r=me

WebKit Commit Bot

Comment 11 2015-03-06 17:39:29 PST

Comment on attachment 248114 [details] Fix 2 Clearing flags on attachment: 248114 Committed r181195: <http://trac.webkit.org/changeset/181195>

Note You need to log in before you can comment on or make changes to this bug.