why i get access violation error when compile in release->multithreaded mode?

[Xiao_Yu]

problem description:
everything is ok when i complile and run the program in release mode,chosing the runtime library->mutithreaded

but when i change the mutithreaded to Multithread DLL (/libs:dll /threads)(everything remain unchanged except ignoring some static libraries), compile and run the program,and i get a access violation error.
what confused me is that this error is uncertain(for example: i add some pause in the program and determined the error exists in one subroutine ,but after i add some write statements and find the error now exist in another subroutine )

and when i choose the debug mode(as i want to locate the error)but i get the right result both in (debug mutithreaded) and (debug mutithread dll).

My os is win7 x64,platform is vs2010+fortran composer xe 2011

[Steven_L_Intel1]

This sounds as if you are accessing outside the bounds of a variable and the behavior depends on uninitialized memory. Any change you make in memory layout can change the results.

[Xiao_Yu]

question 1 :
I know the access violation error come from the accessing outside the bounds of a arraybut why i get the right result in debug mode and release mode(Multithread DLL),and get error in release mode(Multithreaded).
what's the difference between Multithread DLL and Multithreaded causing this kind of error.
ps:I modified my code,now it's wrong even in release mode(Multithread DLL).It seems like the key of the problem lie in the difference between debug mode and release mode.If I use the unallocated memory the result in debug mode should be wrong,but the result is exactly right.

question 2 :
I invoke old f77 subroutine which the dummy parameter is like

subroutine addblk(nrowa, ncola, a, ja, ia, ipos, jpos, job,
& nrowb, ncolb, b, jb, ib, nrowc, ncolc, c, jc, ic, nzmx, ierr)
c implicit none
integer nrowa, nrowb, nrowc, ncola, ncolb, ncolc, ipos, jpos
integer nzmx, ierr, job
integer ja(1:*), ia(1:*), jb(1:*), ib(1:*), jc(1:*), ic(1:*)
real*8 a(1:*), b(1:*), c(1:*)

and i call this subroutine in one class

MODULE SPMCSR_CLASS
IMPLICIT NONE
TYPE,PUBLIC :: SPMCSR
........
CONTAINS

PROCEDURE,PUBLIC :: ADD

END TYPE SPMCSR

CONTAINS

SUBROUTINE ADD(...)
...
CALL addblk(nrowa, ncola, THIS%A, THIS%JA, THIS%IA, M, N, job,&
nrowb, ncolb, SPMIN%A, SPMIN%JA, SPMIN%IA, nrowc, ncolc, c, jc, ic, nzmax, ierr)
...
END SUBROUTINE

END

one access error i determined maybe in the line (CALL addblk),can i modify my code(not the old f77 code)so as to get compile error in debug mode when the compiler check the bound of array.I noticed in textbook that i can add some interface in my module,Is it designed to solve this kind of problem?
I think i should solve the this problem on my own,It's not just a fortran grammer problem.

[John_B__Walter]

This still sounds like an array bounds problem. As Steve said, anything that changes how things are laid out in memory can change the results, such as using different libraries or adding debugging code. The fact that you are currently getting correct results in the debug version is probably just fortuitous, and not an indication that it is working correctly. It's just that whatever memory you are clobbering with the problem in the debug version is not presently causing an access violation.

Good luck, as this will be difficult if not impossible to find unless you can open yourself to this reality.

[Xiao_Yu]

this error is strange.I executed the same exe file in different folder,one is ok,but the other is wrong.
and i create exactly the same path in another computer,want to reproduce the problem,but the result is ok.
so i only get error in one certrain computer and in certain directory.
I didn't want to waste time on this kind of problem ,so i decided to ignore this error.

[John_B__Walter]

This kind of behavior, where you get differing results, might be due to an array index or a pointer which is not being properly initiallized. Older versions of IVF and also CVF would initialize memory to 0, but the current versions do not by default. Thus noninitialized variables can contain anything.

You should check your fortran properties. Are you warning of uninitialized variables?

Also, keep in mind that there are properties for the project, but also for individual source files which can be different.

Steve -- is there a mechanism to apply project property settings across all the source files once the properties for a particular source file may have been set to be different? Does this make any sense?

[Steven_L_Intel1]

John,

There isn't an option to "promote" individual file properties to the project. There is a subtle indication that a file has file-specific properties set - the little "page" icon has a red corner in the upper left.

What I like to do is go to the "Command Line" page and compare the list of options with whatever else I'm looking at - it's pretty easy to see what, if anything, is different.

[Xiao_Yu]

John,
uninitialized variables?
I thought in debug mode the uninitialized variables is initialized to a very big number,
in release mode the uninitialized variables is initialized to 0 by compiler , by default.
Is fortran 2011 changed this option?
Since my problem'strange behavior, I think this may not be the cause.

the error point to the line where i invoked a old format fortran subroutine.
this subroutine'dummy argument is like
real :: a(*)
and the code is hard to understand,so i can't check the bound of array mannually.
Since the problem is unable to be reproduced in other computer. So I decided to give up.

[Steven_L_Intel1]

Uninitialized variables are just that - uninitialized. They are not set to anything by the compiler, whether in debug or release mode.

You may have found a clue in that the error occurs in a routine that uses assumed-size arrays, where the compiler cannot check the bounds. Can you change the code, as an experiment, to pass in the bounds information as an argument and then use that argument (or arguments) in the routine's declaration of the array bounds?

[Xiao_Yu]

I wrote an alternative subroutine to avoid invoking this "maybe wrong" routine, And now the problem solved.

But I have question about Uninitialized variables

program testrd
implicit none
real x
integer i

write(*,*) x,i
end program

I run this in debug mode,the integer seems a random number,It approved your words.
but the real number is 0.000000e0 every time i run it,It seems the compiler intialized it to 0.

and in release mode,every time i run it, the result is 0.0000000e0 0.
It also seems the compiler intialized the integer and real number to 0.how to explain this?

[mecej4]

Despite appearances, the values seen for uninitialized variables are not necessarily random in a mathematical sense.

What you see is whatever value was placed earlier in the corresponding memory locations. Even if you see zeros output a thousand times today, you cannot assume that you will always see the same output. That's precisely what is meant by "undefined behavior".

Your statement that "the compiler did it" is less valid as a conclusion than "the butler did it" in a Who-Done-It movie.

Just to make the point, here is one such output with the compiler option /Zi :

1.9618179E-44 1245048

[John_B__Walter]

another thing to keep in mind is that, due to how real values are stored in memory, a lot of stray values, if they weren't last used to store a real value, look like 0.0. If you equivalenced the real value to a variable that was integer (kind=1) myint(4), you would probably see something different from 0, 0, 0, 0 for the values of those four bytes, even when the real appeared to be 0.0 (when they had not been initialized).

If you look at more than a few uninitialized real variables you will find some that are different from 0.0

[Xiao_Yu]

Thanks guysyou are so warm-hearted.
I'll take care of those uninitialed value in my code in case of some hard to debug errors occurring.