http://trac.webkit.org/changeset/189774 made Speedometer/Full.html
test crash on the performance bots:
- Apple Yosemite: https://build.webkit.org/builders/Apple%20Yosemite%20Release%20WK2%20%28Perf%29/builds/2904
- Apple Mavericks: https://build.webkit.org/builders/Apple%20Mavericks%20Release%20WK2%20%28Perf%29/builds/5762
- EFL: https://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK2%20%28Perf%29/builds/6860
- GTK: https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Perf%29/builds/4051
I'm sure that r189774 is the culprit, I tested r189773
manually (EFL Linux) and this test works fine on it.
Created attachment 261210 [details]
We are dying trying to execute a StoreBarrier on a local register. This is after a CallVarArgs. The local register is being overwritten with undefined (0xa) by the fixup arity stub on entry to the called function. When we return from the CallVarArgs, the StoreBarrier will fail trying to access a cell at 0xa.
I believe that the argument count and therefore layout and/or position of the varargs callee is wrong. The patch made changes to call frame sizing, with code that rounds up the size of the frame to be stack aligned.
The issue is that we are doing arity checking on a varargs call frame That call frame has two arguments and needs a third. With the size of the call frame header is 5 added to the 2 arguments gives a frame size that is 7 Registers big. The code in this change assumes that call frames are rounded up to stack alignment size. But this one is not. The arity fix up code assumes that there is an extra slot, based on the size of the fixup being one Register slot. It then clobbers the last caller's local which is in the slot assumed to be unused.
I have tried a couple methods to make the call frame size be stack size aligned, but these proposed fixes cause other tests to fail.
I'm going to roll out the r189774 and r189818, the C Loop fix from https://bugs.webkit.org/show_bug.cgi?id=149171 and then debug locally before landing the original patch with a fix.
Landed roll out in changes r189848 <http://trac.webkit.org/changeset/189848>