Debugging issues

[jimdempseyatthecove]

Steve,

I am using W_FC_C_9.1.032 (downloading .034 as I type this post) and running on VS2005 SP2 (both WinXP x32 and Windows Server x64).

While debugging, at a break point in the source file, I can specify

aPointer.MemberVariable

In the Watch window or QuickWatch or InteliSense with "aPointer.MemberVariable" and see the contents of the memory location in the formatdeclared.

However, if I open a Memory window, I can specify "aPointer" which bases the memory view window at the base of the structure pointed to by aPointer, but I am unable to specify "aPointer.MemberVariable". (don't know if this is fixed in .034).

The same problem is present when specifying Break on Data Change. In pre-0.32 versions I could specify "aPointer.MemberVariable" at least to the Memory window, obtain the hex address there, then paste the address into the Break on Data Change (remove the 0x prefix, and appent h suffix), then set the break. But now I must display memory at the stare ofthe structure, count bytes, then hand enter the address into the Break on Data Change.

This is somewhat awkward.

By the way, the Language pull-down in Break on Data Change does not include Fortran.

Yea, I could post an issue on Premier, but they are just going to ask me for a sample program...

Jim Dempsey

[Steven_L_Intel1]

Hi, Jim. Got a sample program? Or are you suggesting that I try to create one based on your description and hope that I match what you're doing?

[jimdempseyatthecove]

I am asking if there are similar issues regarging this symptom.

The simple foo testprogram I wrote fails to exhibit this problem. The failure is exhibited in a solution with several 100's of files, 8 projects (7 libraries). So no, I don't have a sample program.

I know your life would be easier if you have a simple failing test program. But life isn't always that easy.

This may be a Visual Studio 2005thing (although it was present in 2003), an IVF integration thing, an IFORT debug symbol table generation thing, some sort of internal table overflow thing.

Jim

[Steven_L_Intel1]

It's not an issue I am familiar with. There can be many possible causes, which is why a test case is so important.

[jimdempseyatthecove]

Back in 1972-74 when I worked on Software Problem Reports for Digital Equipment Corporation I did appreciate the value of having test cases that exhibited the problem.

I did receive one problem report about failing to read a file off a floppy disk (8" floppy). You can appreciate my inability to address the issue due to the fact that the user stapled the problem report to the diskette through the recording media.

Jim

[Steven_L_Intel1]

Well, those 6-part SPR forms were pretty tough... Then again, I remember in 1979 getting SPR reports with an RP06 (removeable hard disk pack weighing about 20lbs) included...

Too many times, though, I've tried to reproduce a problem based on a customer's perceived summary of the code, only to find that everything works fine, and that it was something the customer did not mention (and may not have been aware of) that was the key.