[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 #6 from Akos Kiss <akiss at inf.u-szeged.hu>  2014-09-02 08:18:57 PST ---
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.

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