Debugger in .NET shows the wrong results for allocated derived types

[ulli_u_]

We have the professional version 8.0.048 and we can`t work with this GUI with wrong results for allocated derived types.

What is our problem???
Please help.


an here is the sample:

program test
type STRUCT
real(8) :: X
real(8) :: Y
real(8) :: Z
end type STRUCT

integer(4),parameter :: count=10
integer(4) :: i
type(STRUCT),allocatable,dimension(:),target :: t_var
type(STRUCT),dimension(:),pointer :: p_var

nullify(p_var)
allocate(t_var(count))

do i=1,count
t_var = STRUCT(1.D0,2.D0,3.D0)
end do

print *, t_var(1)%x,t_var(1)%y,t_var(1)%z
! >>>>>>>>>>>>>>>>>>
! this shows right result in console
! but this degugger shows here the wrong results
! <<<<<<<<<<<<<<<<<<

p_var => t_var

if(associated(p_var)) nullify (p_var)
if(allocated (t_var)) deallocate(t_var)

end program test


Regards from dresden,germany

Matthias Friedrich

[Zhanghong_T_]

It seems another bug of IVF8, I have tested in CVF6.6C and found no problem when watching the variables p_var and t_var.

[Jugoslav_Dujic]

It's the same here at 8.0.053.

I've seen this in similar (but not identical) cases; Zhang Hong demonstrated that in an earlier thread. Basically, speaking in C terms, the debugger displays memory contents of (t_var),instead of (t_var*).

Steve are you aware of that problem? We have been there already in... can't find the thread, but it was rather long time ago.

Jugoslav

[Steven_L_Intel1]

I have seen some problems of that nature, and those I know about have been fixed. If the problem persists in the latest version (8.0.53 at this writing), please send an example to Premier Support.

[williamrrichmond]

Hello:

I'm also having debugger problems- version 8.0.050_pe053 - and I'm unable to access information nested within subroutines. I've attached a zip file with a sample problem,console2.zip

Here'sa brief rundown of the contents of the zip file:

main project file for Console2

Console2.f90 - This is the main source file for the Fortran Console application.
It contains the program entry point.

global.f90 - global module containing global declarations used through the program

mod1.f90 - module containing type declarations

sub1.f90 - subroutine to read in some data - uses a contained subroutine readinfo

You can't access the variable grp03 (a variable using a defined structure) in the
debugger even though the program successfully reads, and then writes out the informationin the structure. As well, even within console2.f90, you can't see the grp03 variable even though it's in scope.

Bill

Note for Steve:

If you're following this, Steve, I've also submitted this to Intel Premier Support as Issue Number #263998. There hasn't been any response from Support since I submitted the example to them on Aug 31, 2004.

Thanks,

Bill

[Steven_L_Intel1]

Bill,

I see the case in our system. I note that you gave it a priority of "showstopper" - is this really appropriate? I can understand that it's a serious problem but does it really block you from making progress on your application development?

[williamrrichmond]

Steve:

Thanks for the quick reply. No, it's not really a "showstopper" per se but to get over the problem I've reverted to my authorized copy of CVF 6.1A to do the debugging I need. Perhaps a category "extremely frustrating and irritating" would be most appropriate. However, I will change the category for this issue to the next lower level.

In the meantime, I'm trying to use the Intel debugger. Is there some way of setting the working directory, i.e. the directory that the developer wants the input to come from? I've looked through the debugger documentation and failed to find anything that relates to the working directory. Otherwise, I've got to put the data files for my program in amongst the source files.

Thanks for your help.

Bill

[Steven_L_Intel1]

This works the same way as it does in CVF. The default is the project directory - the one the .vfproj file is in. You can change this in the project properties Debug page.

[williamrrichmond]

Steve:

Thanks again for your quick reply. However,your answerapplies to the IDE under .NET, doesn't it? Unfortunately, because of the problem in this thread, I can't access the information about variables in the .NET debugger.

So, I was thinking the problem may not be present in the Intel debugger, i.e. the command line debugger. So, the question is how do Iset the working in the Intel command line debugger (i.e. Intel Debugger 7.3)?

Thanks,

Bill

[Steven_L_Intel1]

Oh, I misunderstood...

I would expect it to use the current directory (the one you're in when you invoke idb). That's the way almost all command line utilities work.