Bug 93373 – ARM JIT causes segmentation fault

• Status: RESOLVED
• Resolution: INVALID
• Component: JavaScriptCore

WebkitGtk-1.8.1 (GTK2) crashes during the loading of the following page: http://itv.ard.de/ardepg/index.php

Caught signal 11 (at 0x65646f76, invalid address) 

Platform is with the ARMv6TEJ processor. Webkit is built with the enabled JIT. If JIT is disabled there is no crash so I assume that there is some bug in JIT port for ARM. Setting optimization level does not make any difference.

Backtrace:

(gdb) bt
#0  0x31c62568 in JSC::PropertyTable::find (this=0x65646f6e, key=@0x7edce348: 0x46039f20) 
#1  0x31c630a8 in JSC::Structure::get (this=0x4809d6a0, globalData=..., propertyName=...) 
#2  0x31c63158 in JSC::JSObject::getDirectLocation (this=0x48094344, globalData=..., propertyName=...)
#3  0x31d71a84 in inlineGetOwnPropertySlot (this=<optimized out>, exec=<optimized out>, propertyName=..., slot=...)
#4  fastGetOwnPropertySlot (this=<optimized out>, exec=<optimized out>, propertyName=..., slot=...) 
#5  JSC::JSValue::get (this=0x7edce558, exec=0x478bf108, propertyName=..., slot=...) 
#6  0x31dd82a4 in JSC::JITStubThunked_op_get_by_id_self_fail (args=0x7edce5c8) 
#7  0x31dc2028 in cti_op_get_by_id_self_fail () 
#8  0x31dc2028 in cti_op_get_by_id_self_fail () 
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Registers info:

(gdb) info registers 
r0             0xc4df83	12902275
r1             0x65646f6e	1701080942
r2             0x7edce348	2128405320
r3             0x65646f6e	1701080942
r4             0x65646f6e	1701080942
r5             0x200	512
r6             0x768b8	485560
r7             0x45f916c0	1173952192
r8             0x31dc2020	836509728
r9             0x0	0
r10            0x320b32a0	839594656
r11            0x7edce324	2128405284
r12            0x7edce2d0	2128405200
sp             0x7edce2f0	0x7edce2f0
lr             0x31c617a0	835065760
pc             0x31c62568	0x31c62568 <JSC::PropertyTable::find(WTF::StringImpl* const&)+80>
cpsr           0x60000010	1610612752

Obviously "this" pointer in instance of PropertyTable class has invalid value. I tried to go deeper in debugging to find out how those instances are created, but that ends in JIT code generated for ARM and that is unfortunately out of my knowledge. Please ask for any additional info you need.

[Zoltan Herczeg]

Which JIT is enabled? The traditional or the thumb2? (Your CPU supports both)

Sorry, correct information about processor: it is ARM1176JZF-S processor. 

It is ARM traditional JIT. 

Also, I noticed that during the checking for arch version in Platform.h processor identifies itself as ARM_ARCH_VERSION_5, to be more precise as __ARM_ARCH_5T__. During the search I found it should be ARMv6, right? But this depends on the tool chain and  shouldn't be a problem since all code built for the v5 should run on v6 without problems, right?

Bug is not reproducible on the http://itv.ard.de/ardepg/index.php anymore. However page is still not working properly. For some reason some JS variable suddenly becomes undefined. 

Problem is still reproducible on e.g. www.google.com. Backtrace is the same (of course, with different addresses).

If I build debug version of Webkit, it crashes much earlier due to failed assertions:

Program received signal SIGSEGV, Segmentation fault.
0x32b2e39c in JSC::JIT::endUninterruptedSequence (this=0x7ec47cb8, insnSpace=56, constSpace=3, dst=1) at Source/JavaScriptCore/jit/JITInlineMethods.h:182
182	    ASSERT(differenceBetween(m_uninterruptedInstructionSequenceBegin, label()) <= insnSpace);
(gdb) bt
#0  0x32b2e39c in JSC::JIT::endUninterruptedSequence (this=0x7ec47cb8, insnSpace=56, constSpace=3, dst=1)
#1  0x32b53e30 in JSC::JIT::compileGetByIdSlowCase (this=0x7ec47cb8, dst=1, base=1, ident=0x1d69d0, iter=@0x7ec47b08: 0x223340, isMethodCheck=false)
#2  0x32b54038 in JSC::JIT::emitSlow_op_get_by_id (this=0x7ec47cb8, currentInstruction=0x244f68, iter=@0x7ec47b08: 0x223340)
#3  0x32b301c4 in JSC::JIT::privateCompileSlowCases (this=0x7ec47cb8)
#4  0x32b32e1c in JSC::JIT::privateCompile (this=0x7ec47cb8, functionEntryArityCheck=0x0)
#5  0x32c64134 in JSC::JIT::compile (globalData=0xce1f0, codeBlock=0x1f9a00, functionEntryArityCheck=0x0)
#6  0x32c64690 in JSC::jitCompileIfAppropriate<JSC::ProgramCodeBlock> (globalData=..., codeBlock=..., jitCode=..., jitType=JSC::JITCode::BaselineJIT)
#7  0x32c5e870 in JSC::ProgramExecutable::compileInternal (this=0x4833ff60, exec=0x482ffcb8, scopeChainNode=0x4831ffe0, jitType=JSC::JITCode::BaselineJIT) 
#8  0x32b0ea40 in JSC::ProgramExecutable::compile (this=0x4833ff60, exec=0x482ffcb8, scopeChainNode=0x4831ffe0)
#9  0x32b05d08 in JSC::Interpreter::execute (this=0x81f00, program=0x4833ff60, callFrame=0x482ffcb8, scopeChain=0x4831ffe0, thisObj=0x482bffc0)
#10 0x32c485b4 in JSC::evaluate (exec=0x482ffcb8, scopeChain=0x4831ffe0, source=..., thisValue=..., returnedException=0x7ec495d0)
#11 0x3039663c in WebCore::JSMainThreadExecState::evaluate (exec=0x482ffcb8, chain=0x4831ffe0, source=..., thisValue=..., exception=0x7ec495d0)
#12 0x303e87dc in WebCore::ScriptController::evaluateInWorld (this=0x6c300, sourceCode=..., world=0x839f8)
#13 0x303e8b3c in WebCore::ScriptController::evaluate (this=0x6c300, sourceCode=...)
#14 0x307f4514 in WebCore::ScriptElement::executeScript (this=0xf55f0, sourceCode=...)
#15 0x313a8ad8 in WebCore::XMLDocumentParser::notifyFinished (this=0xa9000, unusedResource=0xe89a8)
#16 0x30c66c20 in WebCore::CachedResource::checkNotify (this=0xe89a8)
#17 0x30c8148c in WebCore::CachedScript::data (this=0xe89a8, data=..., allDataReceived=true)
#18 0x30d27508 in WebCore::SubresourceLoader::didFinishLoading (this=0xffdd8, finishTime=0)
#19 0x30d16810 in WebCore::ResourceLoader::didFinishLoading (this=0xffdd8, finishTime=0)
#20 0x30f8b800 in WebCore::readCallback (source=0x45608, asyncResult=0xc1c40, data=0xe8d48)


In above case difference is 60 (should be <= 56).

If I disable above assert (for testing) it crashes on following assert:

ASSERTION FAILED: JIT Offset "patchOffsetGetByIdSlowCaseCall" should be 48, not 52.
ASSERT_JIT_OFFSET(differenceBetween(coldPathBegin, call), patchOffsetGetByIdSlowCaseCall);

Stack trace is same as above, starting from #1 (JSC::JIT::compileGetByIdSlowCase)

For another test I've changed patchOffsetGetByIdSlowCaseCall to 52. Then it crashes with reversed values: 

ASSERTION FAILED: JIT Offset "patchOffsetGetByIdSlowCaseCall" should be 52, not 48.
ASSERT_JIT_OFFSET(differenceBetween(coldPathBegin, call), patchOffsetGetByIdSlowCaseCall);

Stack trace is again same as previous.

Same as for the original issue, there are no problems with asserts when JIT is disabled. Hope this info for assert fails will give better insight what is the problem.

Following this new info, should I change name of this bug, or open new one for this assert fail?

[Gavin Barraclough]

This code no longer exists; this problem is likely fixed (we no longer rely on fixed offsets for repatching).  If you're still seeing a crash, please attach a new backtrace.