VS2k10 memory window shows ????s when debugging x64 code

[mford78]

My coworker and I are in the process of moving to VS2010 and Intel Composer XE (stepping up from VS6 and Compaq 6!) and I have run into an odd issue I can't find any information 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.

I 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, if I build and debug the code when targeted to Win32 (x86), it works just as expected (memory view and data break points). I created an extremely simple test program, targetted it for x64 and it works as well, but its memory addresses of the variables are much, much lower. Has any one seen such behavior before? I am not sure where to go to get more information. I will continue to try and build a simple test program that reproduces this behavior so that others may be able to help more.

This is all being done under Visual Studio 2010 Pro, Intel Composer XE 12.0.4.196, Windows 7 64-bit. Thanks.

[Steven_L_Intel1]

I just tried a test and, when I typed in a variable name in the Memory window, it correctly showed me the 64-bit address. If you can come up with a test case, I'd like to see it.

[mford78]

Steve, perhaps a silly question then: Does (should) a 64-bit address look different from a 32-bit address? When I use the LOC(var), I get a memory address in the form of a decimal address, which I convert to hexadecimal (one that is very (oddly) large, in the 0x9....... or 0xA....... ranges)like I would when examining any other program (32-bit, this is my first time debugging 64-bit code).

Perhaps there is something more fundamental that I am missing. Thanks for your help, I'll continue to try and get a test program that exhibits this behavior.

[Steven_L_Intel1]

Well, it's longer... In the memory window 64-bit addresses display with 16 digits if they exceed the 32-bit address space. For example, 0x000000013FBD50E0 LOC returns an address-sized integer, so make sure that if you are assigning it to an integer that you declare it as INTEGER(INT_PTR_KIND()).

[mford78]

Okay, I have some more information that will hopefully help others help me pin down this problem.

Based on Steve's post, if I simply type the variable name (as opposed to LOC(varname))into the memory window, it does indeed bring up a valid memory region and shows me what is in there!... sometimes. It looks like it works with variables as long as they are not implicitly defined.

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. Thanks again for any help people can offer.

EDIT: I crossed posted with Steve. Thanks for the additional info. I was correct about what are and are not 64-bit addresses.

[mford78]

I have come up with a test case that exhibits (similar) behavior.

[fortran] program fortBreakTest

    implicit none

    ! Variables
    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
    enddo

    i = 1

    j = 2*i

    do i = 1, 10
        k = k + i
    enddo

    print*, "I, J, K = ", i, j, k

    end program fortBreakTest[/fortran]

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))

#0000000140216298

Pasting 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 (#0000000140216298) into the Memory Window's 'Address:' field brings up 0x7FFFFFFF and displaysa lot of ???????s.

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.

[mford78]

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.

[Steven_L_Intel1]

Interesting - thanks. I'll play with this some and see what I can figure out. I do note that if I click the "Reevaluate automatically" button just to the right of the Address field, then the view remains correct as I step. Something is causing it to truncate the address back to 32-bits inappropriately.

[jimdempseyatthecove]

You cannot (successfully) paste "#0000000140216298" into the memory address window.
Paste 0x0000000140216298 or 0x140216298 into the window

If you paste 0000000140216298 this will attempt to view at the decimal address 140216298, which is 0x85B87EA
Should this address not be mapped into your virtual memory you will see ???????'s

Jim Dempsey

[jimdempseyatthecove]

>>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

This is strange. I've never seen this before. This is behaving as if the "rememberance" of the memory address is passing through a 32-bit process or DLL. IOW something is thunking between x64 and x32 when you single step.

Make a 64-bit C/C++ program to do the same thing (memory view of address of stack variable, then single step).
If this bungs up the same way, then reinstall Visual Studio.

Jim Dempsey

[mford78]

Jim Dempsey wrote:
"You cannot (successfully) paste "#0000000140216298" into the memory address window.
Paste 0x0000000140216298 or 0x140216298 into the window"

Attempting to do either simply causes the Memory View window to display address 0x7FFFFFFF (and all the unallocated virtual memory that exists around there.)

Jim Dempsey wrote:
"Make a 64-bit C/C++ program to do the same thing (memory view of address of stack variable, then single step). If this bungs up the same way, then reinstall Visual Studio."

Jim, per my above post (http://software.intel.com/en-us/forums/showpost.php?p=162535), I did exactly this. The VS C++ compiler/debugger combo handled 64-bit addresses without any issue. The issue appears to be limited to the Fortran debugger and only when the code is targeted to a 64-bit architecture.

[jimdempseyatthecove]

>>The issue appears to be limited to the Fortran debugger and only when the code is targeted to a 64-bit architecture

Got it.

BTW this is odd in itself. If you notice that when you do a memory watch by typing in a variable name you see the variable name replace with the hex address. This hex address should carry over from step to step, but apparently it is not. Margaritavillian - how it got there I haven't a clue.

Jim

[SergeyKostrov]

Hello everybody,

I wonder if a Linker option "Support Addresses Larger Than 2 Gigabytes" could be "responsible" for a really strange behavior?

Look at enclosed Jpg-file: "VS C++ Linker Props Window.jpg".

Best regards,
Sergey

[jimdempseyatthecove]

mford78 is using x64 Platform not x32 (Win32). The Enable Large Addresses feature is for 32-bit programs that are larger than 2GB but smaller than 3GB. You also need a boot time option to enable user space to exceed 2GB (on 32-bit platform).

x64 builds still have a restriction of static data not exceeding 2GB (this restriction applies to a linker load segment size). Allocated memory can be to any of the virtual address space mapable addresses. As to what this is, it depends on the processor model. 48, 50, 52 54 bits. Newer processor models may exceed this.

mford78 also stated this applies to IVF (not C++). It may be time for him to uninstall all versions of Intel Visual Fortran (Composer Fortran), then re-install. The newer releases of IVF permit multiple versions to be concurrently installed (and version chosen from MS VS IDE project property page). It could be that an alternate version of IVF got loaded with only the 32-bit toolchain. unloading all, reloading what he wants may untangle this.

Jim Dempsey

[Steven_L_Intel1]

Jim,

While there can be multiple compiler versions installed, there is only one VS integration available - the latest installed.

[jimdempseyatthecove]

>>While there can be multiple compiler versions installed, there is only one VS integration available - the latest installed.

So then IF, for example, mford78 had

Version 12.34.56 installed as x64 (with his projects using Version 12.34.56)
Then IF mford78 installed Version 12.34.57 x32 compiler
AND if mford78 did not update his project(s) to use Version 12.34.57
THEN mford78 could continue to perform x64 builds using the prior Version 12.34.56
(without noticing that installing a compiler update does NOT update projects to use the newer version)
AND thus may have 32-bit integration (from Version 12.34.57) replacing 64-bit integration from prior version.

(this is complete speculation on my part)

This could be confirmed by mford78 by looking at the project property sheet to see which IVF compiler version is being used. And if the older one, then by changing to newer version and attempting a rebuild. If the speculation is correct the rebuild will fail due to lack of x64 compiler.

Jim Dempsey

[Steven_L_Intel1]

No, I doubt it's that complicated. Let me play with this some more and I'll get back to you.

[mford78]

Jim, this is on a coworkers computer, so I can't *guarantee* he hasn't done smething like that with 100% absolute certainty, I am quite sure he has only ever installed a single IVF compiler (Intel Composer XE 12.0.4.196) because that is the only version he has at the moment.

:)

- Matt

[mford78]

Steve, I was curious if there was ever any further progress on this issue? If it's been fixed in one of the more recent updates, I'd be happy to test it out.

[Steven_L_Intel1]

Sorry, no progress. I'll see what's up.

[Georg_Z_Intel]

Hello,

for completeness, this was answered here:
http://software.intel.com/en-us/forums/showthread.php?t=105507

I'm going to close the thread at hand.

Best regards,

Georg Zitzlsberger