Question/problem with debugger

jarvusluntatintel · ‎05-19-2010

I am having problems viewing variables inside of derived types. Specifically, when I add a new variable inside the derived type, I do a full clean and full rebuild, the runtime behavior is correct but the new variable does not show up in the debugger.

All of my definitions are in include files (the include files are in a separate directory). So a given declaration (in the attached example I_WEIR_I_STRUC) is only in one place (in this case inside of i_weir_i.i). The derived type I_WEIR_I has been passed into this subroutine as an argument, while I_WEIR_I_TEMP is local to this subroutine. The variable HYDRO_OTHER_PT has just been added to the include file (and everything cleaned and rebuilt). HYDRO_OTHER_PT was set to 1 right before this subroutine was called. The screen shot of I_WEIR_I_TEMP is what I expect.

The subroutine where I_WEIR_I is initially declared is ok, but at some point as it get passed down the chain, the debugger will suddenly revert to showing the "old" definition.

Where does the debugger store this information. I have no idea how the debugger is keeping hold of the previous definition. Is there some hidden file or directory this is stored in? After doing a Clean and before doing the Rebuild, is there some file I can delete to make the debugger get "fresh" definitions?

Thanks

Intel Visual Fortran Compiler Integration Package ID: w_cprof_p_11.1.060

Steven_L_Intel1 · ‎05-21-2010

The debug information is part of the object file. Can you attach a ZIP of a complete solution that reproduces this problem?

jarvusluntatintel · ‎05-22-2010

Steve

Thanks for the reply. While trying to make a cleaner project to upload, the problem went away and I discovered more of what is going on. I had not gotten rid of all the object files, although I still think that the debugger behavoir is far from desirable.

As part of my solution, I have a library project for making reads and writes to HDF5 (an open source data base). I had hooked this up a long time ago, but my office pushed HDF5 off to the back burner.

I did not realize that this library and debug directory (../ModLibHDF/Debug) were linked in and on the include path. So it turns out that this is where the debugger was getting the "old" definition. If a subroutine that Used this module/library was having problems with the debugger, I could certainly understand. However, my derived type is declared in asubroutine (it looks ok in the debugger) and then in the first subroutine it is passed to, the debugger starts displaying the old definition. Neither of these routines have any calls to the HDF5 library nor any Use Modules from this project. So this is the part I think is less than desirable.

I don't think I was getting this behavoir back when I was using version 9. My archive solutions also have the HDF5 links in the debug version and I add new variables on a fairly routine basis and it is pretty apparent when a just added variable does not display. (Although it is certainly possible that I was rebuilding the HDF5project every time I added a variable, I don't find that likely). I skipped from version 9 to version 11.

Now that I understand what is going on, I'm good to go and do not need any support.

If you still want/need a version that shows the problem, let me know. However, it may not be a simple undertaking. HDF5 has a variety of dlls that took me some work to get it all set up (I rather suspect youmight bequicker ;-). My program tries to load the dlls at startup (and if it doesn't find them, it won't execute, even if it doesn't make any HDF5 calls).

Steven_L_Intel1 · ‎05-22-2010

Ok, thanks for letting me know.