[Webkit-unassigned] [Bug 93373] ARM JIT causes segmentation fault

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=93373





--- Comment #3 from rm4dfthings at gmail.com  2012-09-05 07:22:45 PST ---
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?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.