Bug 141498 – [Win] [64-bit] Work around MSVC2013 Runtime Bug

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Brent Fulgham]

Microsoft Visual Studio 2013 has a bug in their 64-bit runtime libraries that causes a crash with error "0xC000001D: Illegal Instruction" if the CPU does not support the AVX2 instruction set. Apparently, the runtime library does not properly recognize when the AVX2 set is not present (or if it has been disabled in the firmware) and attempts to use them regardless of CPU support. Microsoft apparently does not plan to address this in any VS2013 update. The VS2015 environment does have a correction for this.

Until Microsoft releases VS2015 (and this project migrates to it), our only recourse is to disable the use of FMA3 in the math library.

See <https://connect.microsoft.com/VisualStudio/feedback/details/811093/visual-studio-2013-rtm-c-x64-code-generation-bug-for-avx2-instructions> for some comments from Microsoft on this topic.

[Brent Fulgham]

<rdar://problem/19803642>

[Brent Fulgham]

Microsoft: "“Thank you for reporting this issue. This is indeed a bug in the instruction set availability detection in the math library of the Visual C++ 2013 C Runtime (CRT). The bug occurs when [1] the CPU supports FMA3 and [2] either the operating system does not support AVX or support for AVX is disabled in the operating system."

Note that in addition to the hardware restraints I mentioned initially, users can actually create this issue by disabling the AVX instruction sets (even if the CPU does support them):

Disable AVX: bcdedit /set xsavedisable 1

You can re-enable it by:
    bcdedit /set xsavedisable 0

-or-

    bcdedit /deletevalue xsavedisable

[Brent Fulgham]

Created attachment 246424 [details]
Patch

[Brent Fulgham]

Created attachment 246425 [details]
Patch

[Anders Carlsson]

Comment on attachment 246425 [details]
Patch

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

> Source/JavaScriptCore/jsc.cpp:1177
> +    // TODO(141449): Remove this workaround when we switch to VS2015+.

Please use FIXME: here (and a proper bug URL!) Here and all other places.

[Alex Christensen]

I think we should put this into WebKitCreateInstance instead of each executable that uses it.  That way it will fix 3rd party applications, too.

[Brent Fulgham]

(In reply to comment #6)
> I think we should put this into WebKitCreateInstance instead of each
> executable that uses it.  That way it will fix 3rd party applications, too.

The problem is that we have some clients that only use JavaScriptCore.dll, and test programs that only link against WTF, etc., for test purposes.

[Brent Fulgham]

(In reply to comment #7)
> (In reply to comment #6)
> > I think we should put this into WebKitCreateInstance instead of each
> > executable that uses it.  That way it will fix 3rd party applications, too.
> 
> The problem is that we have some clients that only use JavaScriptCore.dll,
> and test programs that only link against WTF, etc., for test purposes.

Also, by putting it in the DllMain we do fix third party applications. We have to pepper all of our code with this setting because we are building with static MSVC runtime linking.

We should be able to go back to dynamic linking soon, which would reduce the need to set this flag all over the place.

[Brent Fulgham]

Committed r179993: <http://trac.webkit.org/changeset/179993>