I originally posted this a while back in the general IVF forum, but no one was quite sure what to do with it. Now that there is a dedicated debugging forum, I'll try here! Here is a summary of what I found, and what went on:
When I attempt to build our code for x64 architecture through VS and
debug it, then view the "Memory windows" during debugging, I get nothing
but ??????'s for all addresses and variants of display types.
can successfully tell the window to display a given address using
LOC(variable) (but going by straight memory address gives problems as it
will show me 0x7FFFFFFF). LOC(variable) works fine, except that no
matter what variable I choose, it shows me nothing. In a possibly
related issue, attempting to use data break points results in the
breakpoints being skipped entirely.
Now, using the immediate window I can get the address of implicitly
defined variables, but when I paste it into the memory window I don't
think it works quite right. If I want to look at the location of implicit_variable_1, I go to the 'Immediate Window' and type LOC(implicit_variable_1)
and get an address, #00000001888EBD20 (which would be a 64-bit address
if I am not mistaken). I then go to the memory window and paste this
address into the 'Address:' field and the memory window brings up
location 0x7FFFFFFF (the 2GB or 32-Bitlimit, if I am not mistaken) and a
whole lot of ??????? (the original question that started this thread).
If I type the variable name implicit_variable_1 directly into
the 'Address:' field, it shows me a memory region starting at 0x00000020
or something equally incorrect (along with said ???????s).
If I switch to the not implicitly defined variable var_1,
and I type its name directly into the memory window's 'Address:' field,
it pops up with a seemingly correct memory location. One that holds
what I am expecting and corresponds to what I get from the 'Immediate
Window' using LOC(var_1). For example, if I type var_1 into the Memory Window, I get address 0x0000000186DAF9F4, and when viewed as a real, it shows me the value that var_1
should have. However, if I turn this around and type the address into
the 'Address:' field directly, I once again get taken to address
0x7FFFFFFF and see all ???????s. Typing LOC(var_1) in the
'Address:' field takes me to 0x86DAF9F4 (seemingly corresponding 32-bit
address, even though it is above the 32-bit addressable space) in the
memory region and shows me all ?????????s.
If I attempt to set a
data break point on the address of the explicitly defined variable
(0x0000000186DAF9F4 or what I presume is its 32-bit equivilent of
0x86DAF9F4) it tells me it is setting a breakpoint "When '0x7FFFFFFF'
changes (4 bytes)" which is clearly incorrect.
It seems to me (in
my only slightly educated opinion) that there is confustion about 32
and 64-bit applications and addressing schemes. That said, I have no
idea if it is a Visual Studio issue, or an IVF issue, or if it is no
issue at all and I just have something set incorrectly
Here is a simple program that is able to reproduce this issue:
double precision, dimension (1000000) :: array
integer :: i, j, k
! Body of fortBreakTest
i = 0
j = 0
k = 0
do i = 1, 1000000
array(i) = i
i = 1
j = 2*i
do i = 1, 10
k = k + i
print*, "I, J, K = ", i, j, k
end program fortBreakTest [/fxfortran] In the debugger I have break points on the i=0 and i=1 lines. If I ask for the location of array(1000000) in the Immediate Window, I get
LOC(array(1000000)) into the Memory Window's 'Address:' field brings up
the memory location 0x40216298 and gives me a whole lot of ????????s in
the display. Pasting the address (0x0000000140216298) into the Memory
Window's 'Address:' field brings up 0x7FFFFFFF and displaysa lot of
Entering array(1000000) in the 'Address:' field
brings up 0x0000000140216298 and shows the contents of that array
element correctly. However, if I take even a single step with the
debugger the Memory Window switches from the correct memory location to
0x7FFFFFFF and displays ????????s all the way around.
Hopefully this will allow you to reproduce what I am encountering and suggest a fix/way around it. Thanks again for your help.
As a quick update, creating a very nearly identical program in C++
(compiled with Visual Studio's C++ compiler, not Intel's) and running
the exact same tests worked just fine. The Memory Window in C++
debuggerhappily accepted addresses in 64-bit form, both if input
directly, or as the address of the array variable.
This occurs(ed) with both IVF 18.104.22.168 and the latest we've tried, 12.1.3526.2010.Thanks for any help people can provide, this bug makes it near impossible for us to begug the 64-bit version of our application and we'd really like to have that ability. I can post screenshots of this behavior if it will help.