[Webkit-unassigned] [Bug 136485] Segmentation fault in WTF::RefPtr<JSC::JITCode>::get()

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Sep 3 10:37:52 PDT 2014


Akos Kiss <akiss at inf.u-szeged.hu> changed:

           What    |Removed                     |Added
 Attachment #237560|                            |review?
               Flag|                            |

--- Comment #1 from Akos Kiss <akiss at inf.u-szeged.hu>  2014-09-03 10:37:56 PST ---
Created an attachment (id=237560)
 --> (https://bugs.webkit.org/attachment.cgi?id=237560&action=review)
WIP patch

This is a work in progress patch (at least the Changelog has not been prepared). I think that it may fix not only this bug but https://bugs.webkit.org/show_bug.cgi?id=132740 and https://bugs.webkit.org/show_bug.cgi?id=136436 as well. I believe that all these bugs should be treated together, since they seem to be releated (all of them are caused by relying on assumptions on how the call stack is laid out).

What it does:
- makeHostFunctionCall (both 32_64 and 64 versions) does not add sizeof(CallerFrameAndPC) to sp before the call to entry anymore (which made them rely on calling conventions to fill in caller frame, but also caused the overlap of the stack area of globalFuncProtoSetter with the caller frame).
- Reorganized makeHostFunctionCall (both 32_64 and 64 versions) a bit to be more alike (helps future maintenance).
- Moved the setting of the caller frame of execCallee from JSC::operationCallEval to JIT::compileCallEval (to satisfy what's written in a comment in JIT::compileOpCall, "Caller always [...] Initializes [...] CallerFrame")
- Also changed compileCallEval (both 32_64 and 64 versions) not to rely on calling conventions and keep caller frame and stack of operationCallEval separate.

- X86-64/EFL and X86-32/EFL passed all jsc tests correctly
- the ARM64/EFL test run is ongoing, but the test cases that previously caused problems (the cyclic proto test case included) have been tested manually and passed
- a Thumb2/EFL test run is also ongoing

Acknowledgements to Michael Saboff and Zan Dobersek, since this patch took "inspiration" from their patches.

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

More information about the webkit-unassigned mailing list