[Webkit-unassigned] [Bug 139851] JSC::VM::m_lastStackTop initialized incorrectly when on non-main fiber; runaway memory corruption

[bugzilla-daemon at webkit.org]

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

--- Comment #2 from Michael Saboff <msaboff at apple.com> ---
(In reply to comment #0)
...

> So the value of JSC::VM::m_lastStackTop depends on what's in the
> thread-local storage provided by wtfThreadData(), and the only other write
> to thread-local storage not covered above is:
> 
> JSC::initializeThreading():
> 	std::call_once(initializeThreadingOnceFlag, []{
> 		// ...
>        
> wtfThreadData().setSavedLastStackTop(wtfThreadData().stack().origin());
>     });
> 
> There are 2 problems here.  First, JSC::initializeThreading() is only called
> once for the whole process, so the saved last stack top in thread-local
> storage will only be for one thread in the process.

Although we only call JSC::initializeThreading() once from the main thread, we do initialize wtfThreadData() for any other thread that accesses WebKit.  This is done by the first call to wtfThreadData() for those secondary threads.  The initialization of m_savedLastStackTop is done in the default constructor of WTFThreadData() where we set it to stack().origin().

To be sure, I verified this with one of the worker tests that creates a worker on a secondary thread.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141223/099a58a6/attachment-0002.html>