Bug 201664 – [JSC] CodeBlock::calleeSaveRegisters should not see half-baked JITData

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Yusuke Suzuki]

[JSC] CodeBlock::calleeSaveRegisters should not see half-baked JITData

[Yusuke Suzuki]

Created attachment 378505 [details]
Patch

[Yusuke Suzuki]

<rdar://problem/52126927>

[Yusuke Suzuki]

Comment on attachment 378505 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=378505&action=review

> Source/JavaScriptCore/ChangeLog:25
> +        (JSC::CodeBlock::ensureJITDataSlow):

This crash exists so long time since previously we are seeing half-baked CodeBlock::m_calleeSaveRegisters instead of JITData.

[Yusuke Suzuki]

Committed r249740: <https://trac.webkit.org/changeset/249740>

[Saam Barati]

Comment on attachment 378505 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=378505&action=review

> Source/JavaScriptCore/bytecode/CodeBlock.cpp:1349
> +    // But we should not see garbage pointer in that case. We ensure JITData::m_calleeSaveRegisters is initialized as nullptr before exposing it to BaselineJIT by store-store-fence.

do the compiler threads check for nullptr?

We're seeing this crash on ARM only?

[Yusuke Suzuki]

(In reply to Saam Barati from comment #5)
> Comment on attachment 378505 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=378505&action=review
> 
> > Source/JavaScriptCore/bytecode/CodeBlock.cpp:1349
> > +    // But we should not see garbage pointer in that case. We ensure JITData::m_calleeSaveRegisters is initialized as nullptr before exposing it to BaselineJIT by store-store-fence.
> 
> do the compiler threads check for nullptr?

Yes, compiler thread is checking nullptr.

> 
> We're seeing this crash on ARM only?

Yes, this crash is happening only on ARM devices, because x86 offers TSO.
Theoretically, we can see x86 crash if clang emits the code storing JITData pointer to CodeBlock before null-ing that field.