IVF8 with VS2003 watch window display incorrect value

[pweic]

I am writting a program with some derived type using module. I am using IVF8 and MS Visual Studio 2003.

The problem is that the watch window of VS2003 shows incorrect value for some of the variables in the derived type. Like instead of '6' it would show '8983' etc. But if I print those variable to screen or file the correct value are printed. So I am certain is just a problem of the watch window.

If I arrange the order of variable declaration in the derived type the wrong value would change, but they never change to the correct one :(

Also, the same program running under CVF6.1a would show the correct value.

Has anyone encountered the same problem?

Message Edited by pweichong on 03-30-2004 11:29 PM

[Jugoslav_Dujic]

If it isn't a compiler bug, the other possible thing is that you're debugging the wrong executable (see one code but execute totally other .exe), or that debug informations are not in sync.

You can check out the contents of your derived type by opening a "Memory" window (Debug->Windows->Memory) and typing thederived typevariable name there; you'll get a hexadecimal display. It is a bit hard to follow, but you should be able to spot the member in question -- if it's 06 00 00 00 (assuming 4-byte integers), then it's a debugger/compiler bug, but if it's indeed 8983 (17 23 00 00), you're probably debugging the wrong thing.

Jugoslav

[pweic]

Thanks JugoslavDujic.

I tried what you said and the display in the memory window is same as in the watch window. That is I still see those wrong value, e.g. '00002150' which translate to '8528' instead of '6'.

I double checked and I am certain that I am not running the wrong .exe. Anyway as I've mentioned the file or screen printout is always the correct value, e.g. '6' and not those shown in watch and memory window.

So would you think it is a debugger/compiler bug?

[Jugoslav_Dujic]

Huh... it's strange indeed.

Offhand, it doesn't sound like compiler/debugger bug (but I'm not excluding it). Watch and Memory windows output seems consistent, but I can't explain why the printout is different (and why the latter is correct but former not).

One last try would be to print out the address of the variable in question, e.g.

write(*,"(I8,Z8)") YourType%f, LOC(YourType%f)

and see if it matches the address in Memory window. I guess not, but I can not guess the cause of it right now.

Could you attach zipped project (with necessary input files)here so that someone can take a look?

Jugoslav

[Intel_C_Intel]

I have the same problem,

in routine ThreadProc i 'watch' my derived variable GD(1)%P%ID and get some completely different value than what is read from a local integer variable 'i' which has been assigned the value of GD(1)%P%ID.

I also use IVF8.0.047and MS VS 2003

sample project attached

/Bjrn

[Jugoslav_Dujic]

Thanks Bjoern, nice sample.

It indeed looks like compiler bug (producing invalid debug info) or "fortran debugger" bug (misinterpreting the contents).

What you have is

type, public :: T_GDITEM
sequence
integer :: ID = 0
...
end type T_GDITEM

type, public :: T_GDPOINTER
type(T_GDITEM), pointer :: P !=> null()
end type T_GDPOINTER

type(T_GDPOINTER), public, pointer, save :: GD(:)

and it's indeed watchable (but very inconvenient) in memory window if you type GD(1)%P there. However, watch window interprets the expession GD(1)%P as if it was written like:

type, public :: T_GDPOINTER
type(T_GDITEM):: P
end type T_GDPOINTER

i.e. without pointer attribute -- it displays the memory belonging to GD(1), not memory belonging to GD(1)%p, i.e. garbage.

I recall similar complaints by - I think, Wang Zhanghong. It's a real PITA to debug things like linked lists with this bug.

OTOH, if I replace P with P(:) and allocate it to size 1 (fixing appropriate usages), it works all OK, so the bug appears to occur only on scalar pointers.

I suggest submitting this to Premier if you already haven't. Any additional comments Steve?

Jugoslav

[Steven_L_Intel1]

I think submitting to Premier Support is an excellent idea.