search

microsoft / vstest

Visual Studio Test Platform is the runner and engine that powers test explorer and vstest.console.
MIT License
896 stars 322 forks source link

Q: Does vstest change the MXCSR register? #1314

Closed nietras closed 6 years ago

nietras commented 6 years ago

I am having some issues with reproducibility of tests in the face of a native dll that changes the MXCSR register FTZ (flush-to-zero) and DAZ (denormals-are-zero) bits in DllMain when process is attached.

Running this first time inside Visual Studio causes vstest.executionengine.x86.exe to start and then load the native dll and the test is run. This gives the expected result.

However, upon subsequent test runs inside Visual Studio the test fails, seemingly since the MXCSR register has been reset. Since vstest.executionengine.x86.exe keeps running and keeps the native dll loaded, this means DllMain is not called again.

Forcibly killing vstest.executionengine.x86.exe and running tests again results in the test succeeding again the first time it is run.

My question then is, does vstest´ change/reset theMXCSR` register?

Note, that we only run a single test method. Which only touches well known code in the native dll. The function itself does not set the MXCSR register.

mayankbansal018 commented 6 years ago

@nietras , vstest.executionengine.exe does not explicitly tires to reset MxCsr register, but like you mentioned if you native dll is loaded once in the process, it's DllMain won't be called again. To resolve this issue all you have to do is uncheck Test->TestSettings->Keep exe running option, which would kill vstest.execution engine after every run.

However since VS2017 update 5 we have introduced a new test platform, which will always kill the testhost (new vstest.executionengine) process, where tests are run.

nietras commented 6 years ago

Hi, I am closing this, it appears that for some reason even when using DLL_THREAD_ATTACH that the native dll did not change the MXCSR register for anything but the first thread that actually caused the native dll to be loaded. On subsequent tests different threads are used which do not get the proper bits set in MXCSR and we see differences in floating point results. Not a vstest issue, but an issue with the native dll.