Search code examples
c++visual-studio-2013ssememory-alignmentxna-math-library

Is this a data alignment crash? (potentially involving stack misalignment, XNAMath, Visual Studio 2103)

My Win32, DirectX game is crashing in release mode within code that is manipulating vectors and matrices. Specifically the crash occurs on this instruction:

014E2752 unpcklps xmm1,xmmword ptr [esp+3Ch]

First-chance exception at 0x014E2752 in RodinaRelease.exe: 0xC0000005: Access violation reading location 0xFFFFFFFF

I'm not too experienced with digging into assembly and registers but it appears that esp = 0x0043f31c which would make esp+3Ch = 0x0043f358

Now, according to this and this, the unpcklps instruction is an SSE instruction which requires an alignment of 16 bytes. 0x0043f358 is NOT 16-byte aligned, correct? Am I right in thinking that the alignment of the stack is the cause of my crash?

If so, what did I do to deserve this???? I don't use SSE instructions in my game so I can ignore alignment issues like this - is that naive/wrong? Is there any way to turn this behavior off?

Relevant points:

  • I recently upgraded to Visual Studio 2013 and am suspicious that this bug appeared about this time. I found a bug report that is similar to my problem.

  • My game uses XNAMath, specifically XMMATRIX and XMVECTOR. Normally this would require that I align everything. However, because I didn't want to run into problems like this, I am compiling with the _XM_NO_INTRINSICS_ flag which is supposed to turn off XNAMath's use of SIMD instructions. That has never seemed to be an issue until now. The specific crash that I am dealing with is with my own vector type, but it is in close enough proximity to XMMATRIX code that I believe that it's all mixed together by optimizations.

  • My game is built as a Win32 application. Is switching to x64 a viable solution to this or would that be ridiculous overkill? I don't know what consequences that would have besides needing to get 64-bit versions of libraries I use.

Solution

  • See this answer for more details.

    Keep in mind that VS 2013 for x86 defaults to using /arch:SSE2 so even with _XM_NO_INTRINSICS_ defined, the compiler is going to use SSE/SSE2. For that reason, you should probably stop using _XM_NO_INTRINSICS_ and just get your code to use DirectXMath or XNAMath correctly.

    That said, you can try building with /arch:IA32 to force Visual Studio to use old-school legacy x87 instead of SSE/SSE2...