Bug 154857 – [ARM] ASSERTION FAILED: !(reinterpret_cast<intptr_t>(to) & 1) on Linux

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: JavaScriptCore

[Csaba Osztrogonác]

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.

[Csaba Osztrogonác]

Created attachment 272561 [details]
detailed log

[Csaba Osztrogonác]

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]

Created attachment 272567 [details]
list of the asserting tests

There are 591 asserting tests due to this bug.

[Csaba Osztrogonác]

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]

<rdar://problem/24932068>

[Csaba Osztrogonác]

(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]

(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]

(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]

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 ***