I'm current using Webkit r95542, in case of ARM_TRADITIONAL and enable JIT, crash occurs when clicking any links at http://www.qq.com several times. If I disable JIT then everything goes well. ----------------------------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x000001ac in ?? () (gdb) bt #0 0x000001ac in ?? () #1 0x431a0814 in ?? () #2 0x431a0814 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) PC=0x000001ac LR=0x431a0814, so I investigate the code around LR and I believe this is generated by JIT (gdb) x/20i $lr-32 0x431a07f4: ldr r8, [pc, #1628] ; 0x431a0e58 0x431a07f8: str r8, [sp, #16] 0x431a07fc: mov r0, sp 0x431a0800: str r4, [sp, #96] ; 0x60 0x431a0804: ldr r3, [pc, #1616] ; 0x431a0e5c 0x431a0808: str r4, [r3] 0x431a080c: ldr r8, [pc, #1612] ; 0x431a0e60 0x431a0810: blx r8 0x431a0814: str r0, [r4, #48] ; 0x30 <--- LR is here 0x431a0818: str r1, [r4, #52] ; 0x34 0x431a081c: b 0x4319de6c 0x431a0820: str r0, [sp, #8] 0x431a0824: str r1, [sp, #12] 0x431a0828: ldr r8, [pc, #1592] ; 0x431a0e68 0x431a082c: str r8, [sp, #16] 0x431a0830: mov r0, sp 0x431a0834: str r4, [sp, #96] ; 0x60 0x431a0838: ldr r3, [pc, #1580] ; 0x431a0e6c 0x431a083c: str r4, [r3] 0x431a0840: ldr r8, [pc, #1576] ; 0x431a0e70 so I get following registers r8 and it jumps to the below address > (0x80c7f204), but I can't figure it out why PC lands at the bogus address 000001ac. (gdb) p /x $r8 $1 = 0x80c7f204 (gdb) x/10i 0x80c7f204 0x80c7f204 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2080>: b.n 0x80c7f288 <JSC::HandleHeap::makeWeak(JSC::JSValue*, JSC::WeakHandleOwner*, void*)+52> 0x80c7f206 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2082>: b.n 0x80c7ed24 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+832> 0x80c7f208 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2084>: str r0, [r0, r1] 0x80c7f20a <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2086>: b.n 0x80c7ed48 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+868> 0x80c7f20c <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2088>: ldr r2, [sp, #48] ; 0x30 0x80c7f20e <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2090>: ; <UNDEFINED> instruction: 0xeb00e040 0x80c7f212 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2094>: b.n 0x80c7ed50 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+876> 0x80c7f214 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2096>: str r6, [r1, #0] 0x80c7f216 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2098>: b.n 0x80c7f55a <JSC::appendSourceToError(JSC::CallFrame*, JSC::ErrorInstance*, unsigned int)+130> 0x80c7f218 <JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::ScopeChainNode*, JSC::JSObject*)+2100>: blx 0x8108d55c
r95542 is ancient. Please feel free to re-open if this happens with newest WebKit source code.
Thanks for quick reply alexey. I tried the newest Webkit code and reproduced the same crash in an very recent version(r108450), so I guess this bug still not fixed. By doing more investigation, using different webkit versions to test, I found r94919 is fine, but after I patch changeset 94920 the same crash I met before occured. For more information, I'm using Webkit Qt port based on a armv5 board and enabled JIT, if I disable JIT no crash happened. So maybe modifications relates to JIT in Changeset 94920 is most suspicious, can you re-examine that patch? thanks lu
Thank you for finding the exact revision, CC'ing its authors.