Access violation reading location 0x00000000

[Rob1]

The full error i'm getting is Unhandled exception at 0x0162EF4C in MAIN.exe: 0xC0000005: Access violation reading location 0x00000000

I think this is just a symptom of an underlying problem.  I've been struggling with these types of issues off and on for many years and have never figured out for sure why they happen.

I get this error only with a release build with the following settings:

/nologo /debug:full /O3 /Qipo /fpp /I"C:\Program Files (x86)\Intel\Composer XE\mkl\include\ia32" /I"C:\Program Files (x86)\MATLAB\R2010b\extern\include" /warn:all /debug-parameters:all /fp:fast=2 /Qfp-stack-check /module:"Release\INTERMEDIATE\\" /object:"Release\INTERMEDIATE\\" /Fd"Release\INTERMEDIATE\vc110.pdb" /check:uninit /libs:static /threads /Qmkl:sequential /c

When i run the debug build the program seems to run correctly.

If i throw a simple write statement:

write(*,*) 'hello'

before the line that this error occurred on, the program will run without throwing the error.  If i change the build settings to /O2 I can get it to run but produce incorrect results.

I ran the program in inspector, and i get a critical item "Unhandled application exception" and a "Invalid memory access" on the same line, but i don't see anything obvious that points to a cause for this error.

In my experience with these issues, i've seen lots of strange behavior for example a simple assignment statement where after execution the left hand side doesn't equal the right hand side, but then if the same statement is repeated the value will "stick".

I have no c functions being called (i had thought these were the problem previously).

Has anyone else run into this before?

rob

[mecej4]

Rob wrote:

In #16, the second code snippet shows 

PW_RFP = cross3(B0V_RFP,PA_RFP)/(NRM2(B0V_RFP)**2)     ! <<<CRASH ON THIS LINE

There are two function references here, and both of them require explicit interfaces. I hope that you have made sure of those interfaces being available.

The third code snippet in #16 shows some machine instructions. Are those from cross3 or from NRM2? Did you check that the crash occurs in NRM2?

[Rob1]

For cross3 i am providing an interface in a module, and i'm not doing anything for NRM2 other than USE BLAS95.

MODULE DERIVEDTYPES
...
		INTERFACE
		    FUNCTION cross3(A,B)
			        REAL(8), DIMENSION(3) :: cross3,A,B
		    ENDFUNCTION
	ENDINTERFACE
	
ENDMODULE DERIVEDTYPES

I use these modules in the subroutine that crashes like so:

USE BLAS95
USE DERIVEDTYPES

Jim, thanks for the code example, unfortunately when i include the LOC()<4096 check in cross3 the program runs without crashing.  What is special about the number 4096 and why is being less than it bad?

Thanks app4619, i'll take a look into norm2 at some point.

I ran some static analyses (which by the way anything more than /Qdiag-enable:sc2 crashes vs2012) but so far it just tells me that every argument might be uninitialized.  Could the static analysis help?  Seems like it would be useful for finding function/subroutine argument issues and array issues.

Macej4, from what i can tell the crash occurs in NRM2 but i'm not 100% sure since i'm new at this.  Below are the lines leading up to the crash in order of execution.  I left spaces between non consecutive lines :

005DD076  call        _DNRM2_F95 (065150h)  

00065150  push        ebx  
00065151  mov         ebx,esp  
00065153  and         esp,0FFFFFFF0h  
00065156  push        ebp  
00065157  push        ebp  
00065158  mov         ebp,dword ptr [ebx+4]  
0006515B  mov         dword ptr [esp+4],ebp  
0006515F  mov         ebp,esp  
00065161  push        esi  
00065162  push        edi  
00065163  sub         esp,20h  
00065166  xor         eax,eax  
00065168  mov         esi,dword ptr [ebx+8]  
0006516B  mov         dword ptr [ebp-20h],1  
00065172  mov         dword ptr [ebp-18h],esp  
00065175  mov         edx,dword ptr [esi+18h]  
00065178  test        edx,edx  
0006517A  mov         ecx,dword ptr [esi+1Ch]  
0006517D  cmovge      eax,edx  
00065180  mov         dword ptr [ebp-1Ch],eax  
00065183  cmp         ecx,dword ptr [esi+4]  
00065186  je          _DNRM2_F95+107h (065257h)  

00065257  mov         eax,dword ptr [esi]  
00065259  lea         edx,[ebp-20h]  
0006525C  push        edx  
0006525D  push        eax  
0006525E  lea         eax,[ebp-1Ch]  
00065261  push        eax  
00065262  call        _DNRM2 (01599A0h)  

001599A0  jmp         _dnrm2 (0159840h) 

00159840  push        ebp  
00159841  mov         ebp,esp  
00159843  and         esp,0FFFFFFC0h  
00159846  sub         esp,100h  
0015984C  mov         ecx,dword ptr ds:[75273Ch]  
00159852  mov         eax,dword ptr ds:[0074DC70h]  
00159857  xor         eax,esp  
00159859  mov         dword ptr [esp+0F4h],eax  
00159860  mov         eax,dword ptr [ecx]  
00159862  test        eax,eax  
00159864  mov         edx,dword ptr [ebp+8]  
00159867  jne         _dnrm2+52h (0159892h)  
00159869  push        dword ptr [ebp+10h]  
0015986C  push        dword ptr [ebp+0Ch]  
0015986F  push        edx  
00159870  call        _mkl_blas_dnrm2 (015CAB0h)  

0015CAB0  push        ebx  
0015CAB1  sub         esp,0Ch  
0015CAB4  mov         eax,dword ptr ds:[00768078h]  
0015CAB9  test        eax,eax  
0015CABB  mov         ecx,dword ptr [esp+14h]  
0015CABF  mov         edx,dword ptr [esp+18h]  
0015CAC3  mov         ebx,dword ptr [esp+1Ch]  
0015CAC7  je          _mkl_blas_dnrm2+2Bh (015CADBh)  
0015CAC9  mov         dword ptr [esp+1Ch],ebx  
0015CACD  mov         dword ptr [esp+18h],edx  
0015CAD1  mov         dword ptr [esp+14h],ecx  
0015CAD5  add         esp,0Ch  
0015CAD8  pop         ebx  
0015CAD9  jmp         eax  

00164750  push        esi  
00164751  sub         esp,8  
00164754  mov         eax,dword ptr [esp+10h]  
00164758  mov         esi,dword ptr [eax]  
0016475A  test        esi,esi  
0016475C  jle         _mkl_blas_avx2_dnrm2+0B5h (0164805h)  
00164762  cmp         esi,1  
00164765  je          _mkl_blas_avx2_dnrm2+0A3h (01647F3h)  
0016476B  mov         ecx,dword ptr [esp+18h]  
0016476F  mov         edx,1  
00164774  vmovsd      xmm2,qword ptr ds:[72BD30h]  
0016477C  vxorpd      xmm3,xmm3,xmm3  
00164780  mov         dword ptr [esp],edi  
00164783  vmovapd     xmm1,xmm3  
00164787  mov         ecx,dword ptr [ecx]  
00164789  mov         eax,ecx  
0016478B  sar         eax,1Fh  
0016478E  vmovapd     xmm0,xmm2  
00164792  xor         ecx,eax  
00164794  mov         edi,dword ptr [esp+14h]  
00164798  sub         ecx,eax  
0016479A  mov         eax,edx  
0016479C  vmovsd      xmm4,qword ptr [edi+edx*8-8]            ! <<<CRASH

On another subject, VS2012 professional really doesn't want me using the disassembly/memory/registers windows.  Three times now they have been removed from the menu and the hot keys no longer open them (and yes this is while i'm debugging).  I had them open earlier today, and now they are gone and i didn't even restart VS.  The only way i can get them back is to abort debugging and go to TOOLS>Import and Export Settings>Reset all settings.  I guess at this point it doesn't matter since all my custom settings are already gone, it's just frustrating.  Anyone else run into this?

[mecej4]

I do not think that it is worthwhile to work at the assembly level until you have a small enough reproducer code for which the error consistently occurs in NRM2. In general, when a crash occurs within widely used library routines such as NRM2, I first suspect an incorrect interface or improper arguments. Another reason not to suspect a bug in NRM2 is this: the generic function NRM2 takes only one argument. Short of passing an incorrect descriptor for that argument, what else can go wrong? Here is a simple test program

PROGRAM RBCRASH
USE BLAS95, ONLY : NRM2
IMPLICIT NONE
REAL(8), DIMENSION(3) :: PW_RFP
REAL(8), DIMENSION(3) :: B0V_RFP = [1.0, 2.0, 3.0]
REAL(8), DIMENSION(3) :: PA_RFP  = [-1.0, 3.0, -4.0]                      
REAL(8) :: BNRM2
PW_RFP = cross3(B0V_RFP,PA_RFP)
BNRM2  = NRM2(B0V_RFP)**2
WRITE(*,'(1x,A,2x,4ES12.4)')'CROSS, BNRM2 = ',PW_RFP,BNRM2
WRITE(*,'(1x,A,2x,3ES12.4)')'PW_RFP       = ',PW_RFP/BNRM2
CONTAINS

FUNCTION cross3(A,B)
IMPLICIT NONE
REAL(8), DIMENSION(3) :: cross3,A,B		! 3 element vectors

cross3(1) = A(2)*B(3) - A(3)*B(2)
cross3(2) = A(3)*B(1) - A(1)*B(3)
cross3(3) = A(1)*B(2) - A(2)*B(1)

END FUNCTION cross3
END PROGRAM RBCRASH

This program runs correctly.

I am inclined to suspect from all this that you are not passing a correct argument to NRM2, and that is what I think should be investigated, rather than peering into the guts of MKL routines at the assembly level.

[jimdempseyatthecove]

>>LOC(someVariable) < 4096

On most systems, the virtual memory from location 0 through Page Size-1 are not mapped to physical memory. This is done to specifically help locate memory pointer issues.

Did you change your compiler options? Note, compile the DOSTOP with Debug options, everything else the way it was when you saw the error. You may need to modify the Link command line such that it does not strip out the debug information (for DOSTOP and/or anything else you are compiling with debug information).

If you did not change any options, and by commenting out the test and call to DOSTOP reintroduces the error, then this leads to two possible suspects:

a) Inserting the test and call rearranges the code slightly and the cause of the problem is a coding error that corrupts code. Not where it produces an illegal instruction, but where the effect is not immediately noticed until some time later.

b) Introducing the test made the section made the code non-vectorizable. Try commenting out the test, and adding a #pragma to assure the section/loop is not vectorized. If this fixes the problem then either there is  problem with vectorization of your cod section or a) applies.

In looking at your disassembly code example, while I cannot conclusively confirm this, it appears that mecej4 may be onto something where you are calling a function who's interface was not specified but required. This results in the stack pointer not being restored properly upon return.

00164794  mov         edi,dword ptr [esp+14h]  
00164798  sub         ecx,eax  
0016479A  mov         eax,edx  
0016479C  vmovsd      xmm4,qword ptr [edi+edx*8-8]            ! <<<CRASH

The first line listed above was shown to be returning 0 into edi. Either something corrupted the value stored at the then esp+14h, r esp was not restored properly from call or other compiler bug.

Jim Dempsey

[dboggs]

I also, like many others, had a project that insisted on reporting runtime error 157 Access Violation, only in Release build when it ran OK in Debug. I spent days trying the various debug techniques described here, and systematically eliminated various subroutine and library calls until the program had been reduced to doing nothing: The first executable statement was STOP. The program when run didn't even stop--it just hung on the Access Violation error.

This program had begun life as a Console project, then someone who didn't completely know what they were doing converted it to a Quickwin project by modifying a couple of compiler switches (this is not really the recommended way). I stumbled upon the fact that the linker subsystem switch had been left at /SUBSYSTEM:CONSOLE and changed it to /SUBSYSTEM:WINDOWS. Problem fixed.