[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 #3 from John N. Lehner <jnlehner at yahoo.com> ---
(In reply to comment #2)
> (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().

Yeah, I discovered this this afternoon; see my comment in <rdar://problem/18515908>, which is a similar crash report but with JSC being called on a preemptive secondary thread:

12/22/14, 3:47 PM John Lehner:
OK, WTFThreadData::m_savedLastStackTop is at least initialized to StackBounds::origin(), so that's why we don't see an access violation writing to zero.  But the zeroing of too much memory by the main thread per #139851 was causing the indexingType() to not match any of the supported cases in JSArray::push() (presumably because m_indexingType got zeroed) and that is strikingly similar to jitArrayModeForClassInfo() not matching any supported cases for classInfo->typedArrayStorageType here.

-- 
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/95e7128a/attachment-0002.html>