[Webkit-unassigned] [Bug 136436] REGRESSION(r173031): crashes during run-layout-jsc on x86/Linux

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Michael Saboff <msaboff at apple.com>  2014-09-02 10:07:09 PST ---
(In reply to comment #6)
> Something very nasty is happening here. I've put my hands on an x86/32-bit chroot and built an EFL/debug jsc. When I run jsc --useLLInt=false eval.js, where eval.js is:
> 
> var c = "";
> eval(c);
> 
> I also get the segfault. Running it in gdb and setting a breakpoint at JSC::operationCallEval reveals the following:
> 
> (gdb) disas  JSC::operationCallEval
> Dump of assembler code for function JSC::operationCallEval(JSC::ExecState*, JSC::ExecState*):
>    0x08808885 <+0>:     push   %ebp
>    0x08808886 <+1>:     mov    %esp,%ebp
>    0x08808888 <+3>:     push   %ebx
>    0x08808889 <+4>:     sub    $0x34,%esp
>    0x0880888c <+7>:     call   0x86bfa30 <__x86.get_pc_thunk.bx>
>    0x08808891 <+12>:    add    $0xc8476f,%ebx
> => 0x08808897 <+18>:    mov    0x8(%ebp),%eax
> 
> At this point, esp=0xffffcda0 and ebp=0xffffcdd8 (the difference between them is 0x38, just as expected from the code above). The contents of the stack from *ebp are:
> 
> 0xffffcdd8: 0xffffce28 // <=ebp, this is the result of push %ebp, i.e., before calling operationCallEval, ebp was 0xffffce28
> 0xffffcddc: 0xf5f1eef0 // this is the return address pushed on stack by the call to operationCallEval
> 0xffffcde0: 0xffffce28 // this is the first argument of operationCallEval, i.e., ExecState* exec (the previous ebp)
> 0xffffcde4: 0xffffcdd8 // this is the second argument of operationCallEval, i.e., ExecState* execCallee
> 
> And this last line is strange: execCallee should point to a region of memory which has the layout of { callerFrame, returnAddress, codeBlock, scopeChain, callee, argCount, thisArg, args... }. However, in this case, the arguments of operationCallEval (i.e., the pointers exec and execCallee) on the stack are overlapping with the contents of execCallee itself. So, calling execCallee->setCodeBlock(0) zeros out execCallee[2], which is also exec.
> 
> "Interestingly", this was also happening before the patch landed in r173031, but fortunately, exec was not used after the call to setCodeBlock, so the problem did not reveal itself. So, swapping the lines acts as a workaround but there is something nastier underneath, which would be worth of investigation. IMHO.

I don't think that this is due to r173031.  The issue is likely that the space pointed to by execCallee overlaps the stacked argument location on architectures that pass arguments via the stack.  In JIT::compileCallEval(), we use the stack pointer as the calleeFrame pointer and then make the call via callOperationNoExceptionCheck().  For X86-32, we use poke(reg, offset) where the offset is a positive offset of the stack pointer to pass the arguments.

I think requires that we either move up execCallee in the stack (harder) or move down the outgoing argument area for architectures that use stacked arguments (easier).

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