Bug 88355 – Entry into JSC should CRASH() if the Heap is busy

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Mark Hahnenberg]

Interpreter::execute() returns jsNull() right now if we try to enter it while the Heap is busy (e.g. with a collection), which is okay, but some code paths that call Interpreter::execute() allocate objects before checking if the Heap is busy. Attempting to execute JS code while the Heap is busy should not be allowed and should be enforced by a release-mode CRASH() to prevent vague, unhelpful backtraces later on if somebody makes a mistake. Normally, recursively executing JS code is okay, e.g. for evals, but it should not occur during a Heap allocation or collection because the Heap is not guaranteed to be in a consistent state (especially during collections). We are protected from executing JS on the same Heap concurrently on two separate threads because they must each take a JSLock first. However, we are not protected from reentrant execution of JS on the same thread because JSLock allows reentrancy. Therefore, we should fail early if we detect an entrance into JS code while the Heap is busy.

[Mark Hahnenberg]

Created attachment 145857 [details]
Patch

[Geoffrey Garen]

Comment on attachment 145857 [details]
Patch

r=me

Can we put one of these assertions into the allocation slow path as well?

[Mark Hahnenberg]

> Can we put one of these assertions into the allocation slow path as well?

Will do.

[Mark Hahnenberg]

Committed r119518: <http://trac.webkit.org/changeset/119518>

[Geoffrey Garen]

>     ASSERT(!m_heap->isBusy()); 

Actually, I had a CRASH() on the allocation slow path in mind.