When a write statement "solves" a NaN problem -- what gives?

[Tim_Mullin]

I confess that, while I'm not a bad Fortran programmer, my skill with compiler and Visual Studio debugging tools sucks. I have a problem in a routine where I want to write a real numberto, say, the screen. The value appears as NaN. Now, if I execute a write statement just prior to the screen write, and write something, anything, the value reported to the screen in my next write statement is what I expected.

I presume that something is happening in the stack, that is corrected by inserting the earlier write statement.

I'm pulling my hair out here! Any clues how I track down the cause of the NaN value?

[Steven_L_Intel1]

What is likely happening is that the order of data in memory is shuffled by adding the WRITE, so some code that is stomping on your variables is now stomping on something else.

The way I usually debug this is to watch the suspect memory location in the debugger and step through the program watching for it to change unexpectedly. You may even be able to set a watchpoint on it.

[Tim_Mullin]

Quoting - Steve Lionel (Intel)

What is likely happening is that the order of data in memory is shuffled by adding the WRITE, so some code that is stomping on your variables is now stomping on something else.

The way I usually debug this is to watch the suspect memory location in the debugger and step through the program watching for it to change unexpectedly. You may even be able to set a watchpoint on it.

Yup, that sounds logical. Now I just have to figure out how to set watch points and step thru that area of the program. As I suggested -- I sort of lack skills when it comes to using debugging tools!

[cfrieler]

Quoting - Tim Mullin

I confess that, while I'm not a bad Fortran programmer, my skill with compiler and Visual Studio debugging tools sucks. I have a problem in a routine where I want to write a real numberto, say, the screen. The value appears as NaN. Now, if I execute a write statement just prior to the screen write, and write something, anything, the value reported to the screen in my next write statement is what I expected.

I presume that something is happening in the stack, that is corrected by inserting the earlier write statement.

I'm pulling my hair out here! Any clues how I track down the cause of the NaN value?

In the past I've done this type of diagnosis using the debugger as well. It's not fun and fortunately it's been a while since I've had to. The reason is that I adopted a (nearly) strict practice of fully declaring all variables in all my routines and declaring intent for all variables in interfaces. Once I stopped assuming type and shape across interfaces, the occurrence frequency of this sort of bug dropped from "all the time" to "once in a blue moon". If your code is short or compartmentalized in the section that gives the error, I would recommend trying this.

Regards, Cliff

[forall]

Quoting - Steve Lionel (Intel)

What is likely happening is that the order of data in memory is shuffled by adding the WRITE, so some code that is stomping on your variables is now stomping on something else.

The way I usually debug this is to watch the suspect memory location in the debugger and step through the program watching for it to change unexpectedly. You may even be able to set a watchpoint on it.

steve,
how do you view a memory location in the debugger? i presume you mean the actual memory location rather than a variable?

[Jugoslav_Dujic]

Quoting - forall

steve,
how do you view a memory location in the debugger? i presume you mean the actual memory location rather than a variable?

To watch a particular piece of memory, use Debug/Windows/Memory (there are 4 available windows). You may have to type LOC(variable) or hex address in form of 0xABCDEF123.

Tip: Adding ",x" as the suffix in the Watch or QuickWatch window shows the variable value in hex. For example "LOC(variable),x" produces the 0xABCDEF123 form/

To set a breakpoint when the value of a piece of memory changes: use Debug/Breakpoint/New data breakpoint. The accepted values depend on VS version, but typing the address in form of "0xABCDEF123" does the job, mostly. Ignore the fact that Fortran is missing from the language list -- any will do. I think that only 1-4 byte counts work, but that's usually enough. The breakpoint gets auto-disabled in the next debug session. Use sparingly, because it slows down execution.

[Tony_Garratt]

I am working on something very similar. We havea NaN that only shows up in release -O2 builds and goes away if you put write statements in the code or use different compiler options such as -O1 or /fpe:0.

Its almost certainly a memory stomp, but since it doesnt show up in debug mode and write statements move the stomp, its proving a nasty one to track down because a lot of lines of code are being executed and several other routines are being called. So its the classic case of a one of the nasty stomps that is hard to track down.

Just wondered if anyone has any other tips or suggestions please (other than go through all your code and look for a stomp or code writing out of bounds etc).

Thank you!
Tony

[GVautier]

Hello

For me, the first thing to check is subroutines that take assumed size arguments because it is very easy to write out of the bound of the actual argument (dimension xxx(*)) or fixed length character argument because the actual size can be smaller than declared one (character*(n)).