Bug 154857

Summary: [ARM] ASSERTION FAILED: !(reinterpret_cast<intptr_t>(to) & 1) on Linux
Product: WebKit Reporter: Csaba Osztrogonác <ossy>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Critical CC: fpizlo, mark.lam, msaboff, ossy, webkit-bug-importer, ysuzuki
Priority: P1 Keywords: InRadar
Version: Other   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 108645    
Attachments:
Description Flags
detailed log
none
list of the asserting tests none

Csaba Osztrogonác
Reported 2016-03-01 06:27:42 PST
With ARMv7Assembler (Thumb2) I get many assertions like this: ASSERTION FAILED: !(reinterpret_cast<intptr_t>(to) & 1) ../../Source/JavaScriptCore/assembler/ARMv7Assembler.h(2206) : static void JSC::ARMv7Assembler::relinkJump(void*, void*) 1 0xb650ca3c WTFCrash 2 0xb6012fb8 JSC::ARMv7Assembler::relinkJump(void*, void*) 3 0xb6229ca4 JSC::AbstractMacroAssembler<JSC::ARMv7Assembler, JSC::MacroAssemblerARMv7>::repatchNearCall(JSC::CodeLocationNearCall, JSC::CodeLocationLabel) 4 0xb6226d0a JSC::linkFor(JSC::ExecState*, JSC::CallLinkInfo&, JSC::CodeBlock*, JSC::JSFunction*, JSC::MacroAssemblerCodePtr) 5 0xb620815e It's easy to reproduce, it always hits on cdjs-tests.yaml/main.js test . I don't know which revision caused this regression, because I didn't run JSC stress tests in debug mode long time ago.
Attachments
detailed log (1.94 MB, text/plain)
2016-03-01 06:29 PST, Csaba Osztrogonác 		no flags
Details
list of the asserting tests (39.16 KB, text/plain)
2016-03-01 09:53 PST, Csaba Osztrogonác 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Csaba Osztrogonác
Comment 1 2016-03-01 06:29:42 PST
Created attachment 272561 [details] detailed log
Csaba Osztrogonác
Comment 2 2016-03-01 06:39:34 PST
Linking call in localeCompare#CjXQDP:[0xb2a691d0->0xb2a3e2e0, BaselineFunctionCall, 252 (StrictMode)] at bc#173 to (null), entrypoint at CodePtr(executable = 0xb0a1e821, dataLocation = 0xb0a1e820) ASSERTION FAILED: !(reinterpret_cast<intptr_t>(to) & 1) ../../Source/JavaScriptCore/assembler/ARMv7Assembler.h(2206) : static void JSC::ARMv7Assembler::relinkJump(void*, void*) 1 0xb650ca3c WTFCrash 2 0xb6012fb8 JSC::ARMv7Assembler::relinkJump(void*, void*) 3 0xb6229ca4 JSC::AbstractMacroAssembler<JSC::ARMv7Assembler, JSC::MacroAssemblerARMv7>::repatchNearCall(JSC::CodeLocationNearCall, JSC::CodeLocationLabel) 4 0xb6226d0a JSC::linkFor(JSC::ExecState*, JSC::CallLinkInfo&, JSC::CodeBlock*, JSC::JSFunction*, JSC::MacroAssemblerCodePtr) 5 0xb620815e Generated Baseline JIT code for localeCompare#CjXQDP:[0xb2a691d0->0xb2a3e2e0, BaselineFunctionCall, 252 (StrictMode)], instruction count = 252 Source: function (that) { "use strict"; if (this === null) throw new @TypeError("String.prototype.localeCompare requires that |this| not be null"); if (this === @undefined) throw new @TypeError("String.prototype.localeCompare requires that |this| not be undefined"); var thisString = @toString(this); var thatString = @toString(that); if (arguments[1] === @undefined && arguments[2] === @undefined) return @Collator.prototype.compare(thisString, thatString); var collator = new @Collator(arguments[1], arguments[2]); return collator.compare(thisString, thatString); } Code at [0xb0a1e920, 0xb0a20124): .... [ 173] tail_call loc9, loc9, 3, 18 status(Could Take Slow Path) NonArray; predicting None .... It seems the assertion hits near tail call which was added in http://trac.webkit.org/changeset/189884 (bug148661) near half year ago. Could you possible give us any hint what can be the problem here?
Csaba Osztrogonác
Comment 3 2016-03-01 09:53:57 PST
Created attachment 272567 [details] list of the asserting tests There are 591 asserting tests due to this bug.
Csaba Osztrogonác
Comment 4 2016-03-02 02:26:27 PST
Fisr I thought it is related to bug154822, but the bug is still valid with both of the allocators ( on demand / fixed size pool ).
Radar WebKit Bug Importer
Comment 5 2016-03-02 09:29:21 PST
<rdar://problem/24932068>
Csaba Osztrogonác
Comment 6 2016-03-08 01:26:21 PST
(In reply to comment #5) > <rdar://problem/24932068> Does it mean that Apple's JSC port is affected too and you are planning to fix it?
Mark Lam
Comment 7 2016-03-08 07:26:39 PST
(In reply to comment #6) > (In reply to comment #5) > > <rdar://problem/24932068> > > Does it mean that Apple's JSC port is affected too and you are planning to > fix it? I've seen this issue manifest on 32-bit ARM ports. I would like to see it fixed and will try to get to it eventually, but you (or anyone else) is welcome to work on it first if you like.
Csaba Osztrogonác
Comment 8 2016-03-16 06:10:17 PDT
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > <rdar://problem/24932068> > > > > Does it mean that Apple's JSC port is affected too and you are planning to > > fix it? > > I've seen this issue manifest on 32-bit ARM ports. I would like to see it > fixed and will try to get to it eventually, but you (or anyone else) is > welcome to work on it first if you like. Unfortunately I won't have time for it in the near future.
Csaba Osztrogonác
Comment 9 2016-04-15 01:09:51 PDT
I checked the patch in bug150083, it is the same bug as this one. *** This bug has been marked as a duplicate of bug 150083 ***
Note You need to log in before you can comment on or make changes to this bug.