I worked with Visual Studio 2008 in a C project without problems. Now I added the same source files to Visual studio 2010, compiled it without problems but when I debug the program I get:
Unhandled exception at 0x00417257 in da34.exe: 0xC0000005: Access violation reading location 0x00030000.
Looking at the code I just can see this:
; Find next lower page and probe
cs20:
sub eax, _PAGESIZE_ ; decrease by PAGESIZE
test dword ptr [eax],eax ; probe page.
jmp short cs10
_chkstk endp
end
and it points to the “probe page” line
Do you know what could be the reason? My program is very simple.
Thanks
UPDATE:
I found a “cause” of the error just first commenting the content of the main functions, then uncommenting half, and so on. The program consists in one .c and one .h file. In the .h file a type is defined like:
typedef FLOAT_TYPE d_elem[NMAX][NMAX][3];
in the .c file, on the main function, just when the variables are defined, there is a line like:
d_elem d_m;
If I comment this line, the error dissapears. I find this weird, what is going on here ? Of course the whole program compiles and runs with GCC on Linux without these problmes
UPDATE2: The solution (stupid one) is to increase stack reserve size on the project options, linker, etc. Way idiot. VS 2008 with the same default options runs the proram ok
An Access Violation would be one way of your program invoking Undefined Behavior to manifest. There’s a lot of ways to do this in a program, so unless you show us some code that reproduces this, we won’t be able to help you to find this problem.
Edit: It’s the very nature of UB that the results of your program become unpredictable. It worked in VS2008? So what? That’s one way UB might manifest. So the crash goes away when you make random changes? Well, that’s unpredictable for you. Look at this older answer from me regarding UB. (It’s only slightly exaggerated. Really.)
Face it: As long as your program somewhere, somehow invokes Undefined Behavior, anything might happen, at anytime. Try to find the actual problem, and solve it, instead of making random changes that produce random results.
When the crash happens, break into the debugger and look at the call stack, the variables, what the program was trying to do when it crashed, how it got there, which values are nonsense, and why they are nonsense.
This is a shot in the dark, but from what that 3D array looks like, you might recurse too deep, thereby blowing the stack. owever, for that to say you have shown way too little code.