A site for solving at least some of your technical problems...
A site for solving at least some of your technical problems...
Today, as I was trying to run a 64 bit application in Release mode under Windows 7, I got a crash about a NULL pointer. There is the debuggee (<- well known Microsoft spelling of Debugger) error window:
Unhandled exception at 0x52740ccf in guikeyboard_test_developer.exe:
0xC0000005: Access violation reading location 0x0000000000000000.
So... according to this error, the software access a NULL pointer. It took me some time, but the problem was not a NULL pointer, it was an unaligned memory access. In other words, it is trying to write a a pointer that is not 16 bytes aligned, which is necessary with the movaps instructions which is very optimized... but makes your program crash if not properly aligned.
The problem arises when your software makes a copy of 16 bytes (4 integers) in one go. This is an optimization (/O2 or better) and will not occur with lower optimization levels. Also, the /GS flag will prevent the problem by adding the necessary alignment to the stack. But that's only as I was testing and some people say that /GS or /GS- both fail.
There was a post on Microsoft website with a code sample that reproduces the crash. It comes with source code and pre-compiled binaries. If you make changes to the command line options, make sure that the resulting binary still includes the movaps instructions, otherwise it won't crash at all.
I found about the problem because I compiled Qt with VC2010 in 64bit. It can be summarized with:
class QRect { int x1, y1, x2, y2; }; int func() { Var q; q.rect = QRect(); return q; }
Here QRect() is copied in q.rect and then discarded. That copy ends up being a movups (read) followed by a movaps (write). In some circumstances, the write is not aligned to 16 bytes and thus the movaps generates a processor exception.
The following show the two SSE instructions causing the problem. The write (2nd line) is the culprit. The first 2 lines are in INTEL format, the last 2 lines of output are in AT&T format as used by gcc.
000000013F8C1167 movups xmm0,xmmword ptr [rax] 000000013F8C116A movaps xmmword ptr [rdi+10h],xmm0 1400010c5: 0f 10 00 movups (%rax),%xmm0 1400010c8: 0f 29 03 movaps %xmm0,(%rbx)
Re: Compiling in 64bit with VC 2010 can result in a crashing ...
I found your page because I am having this same problem. Unfortunately, neither SP1 nor the hotfix made it go away.
Just thought I'd leave a comment here for others with this problem, to let them know the hot fix will not necessarily fix the issue.