Strange behaviour in IVF10

[NH_Veldhuijzen]

Dear all,

The last few weeks I met with some strange problems when using IVF 10.0.027 and 10.1.011. As I cant see any system in this strange behaviour, I cant construct test programs as illustrations. Note that the strange things happened with programs that ran well when compiled with earlier IVF versions.

What did I see?

- With version 10.0.09, some IF statements seemed to be executed the wrong way. When in fact a condition was .TRUE. the path was taken which belonged to the .FALSE. condition. Inserting a dummy write instruction before those IF statements made the strange behaviour disappear. So did the use of IVF 10.1.011.

- With version 10.1.011, one REAL(KIND=8) variableshowed as aNaN in written output, where it was reported correctly under IVF 10.0.027 and ealier IVF versions. Inserting a WRITE statement or any other debugging statement just before the NaN was written out, resulted in a STACK OVERFLOW!

As I cant see any structure in this madness, and can't construct simple test programs showing the strange behaviour, I am reluctant to send my problems to Premier Support. But perhaps there is someone out there who has similar experiences as I had. If so, please let me know wether you found out what is happenening. Of course, it might be that the new compiler versions have some options changed or set differently, and I didn't notice this.

By the way:

- What is a STACK OVERFLOW? (I could not find any reference to it in the IVF help document).

- What can I do to avoid STACK OVERFLOWs?

Yours sincerely,

Niels H. veldhuijzen

Arnhem, The Netherlands

[NH_Veldhuijzen]

Please read "10.0.027" instead of "10.0.09" in my previous message.

-

Niels

[jimdempseyatthecove]

Niels,

Your strange problems may or may not be related to stack overflow.

The stack is an area of memory which receives the return address, calling arguments (references or values), plus subroutine/function local scalar variables, local automatic arrays, plus descriptors for pointers (but notocal save scalarvariables nor local save arrays/array descriptors). There may be a few other thing that get placed onto the stack here and there.

As your CALL levels go deeper stack consumption increases. As you CALLS return, stack consumption decreases.

For the main (or only) thread of a program the linker specifies the amount of virtual memory to use for stack space. And if none specifies a default value is supplied. If you are using OpenMP, the additional threads each will receive the default stack size but this size can be altered at run time. Once the stack (or stacks in multi-threaded program) is established it remains constant for the duration of the application.

With the above background information stack overflow can be attributed to:

a) Insufficient stack size as default or asspecified by Link option switches (property sheet).

b) Program with infinite (or excessively large) recursion.

c) Creation of very large local variables to subroutines or functions.

Reasons:

V10 may have a different default stack size than V9 (/F)
V10 may have a different behavior for temporary arrays (/heap-arrays[:n])

Jim Dempsey

[Les_Neilson]

Niels,

Is the behaviour the same in both debug and release?
Whatare the IF statements that go wrong ? Can you post the relevant code snippets ?
The insertion ofwrite statements making the IFproblem disappear sounds suspiciously like the problem lies elsewhere - uninitialised variables, array subscripts out of bounds etc.

If you haven't already done so, for good programming practice, all routines should have "implicit none". The debug configuration should have Run-time "Check array and string bounds" and "Check Uninitialised Variables"on.

Les

[NH_Veldhuijzen]

Dear Les,

The software is legacy. There is no "implicit none". It is a set of subroutinesfrom 1988, but up till now it behaved quite well under IVF. So, even if there are ugly things like uninitialised variables ('array subscripts out of bounds' will be flagged), it is enigmatic that the problems arise with IVF10 and not before.

Before I bury you under a lot of code, I think I'll try changing some compiler options (maybe the optimizer settings) and see what'll happen. But thank you very much for your interest.

-

Niels

[NH_Veldhuijzen]

Dear Jim,

Thank you very much for your very insightful lesson in 'stack overflow'. I might try to redefine some compiler or linker options and see what'll happen.

The problem which affects me most, is the one with the Nan showing in the output. With IVF 10.0 and earlier versions, this did not happen (I didn't change the software, not one bit!).

Thank you for taking interest in my problem. If I succeed in overcoming it, I'll let you know.

-

Niels

[Intel_C_Intel]

I had a similar problem once when I changed the number of arguments in a library routine and missed changing a call in another routine. Behavior was similar to what you report, and the problem did not appear near the erroneous call. Very confusing until I spotted the error.

[Les_Neilson]

Ah legacy software! Been there, done that, still there, still doing it!

I am fortunate in that the company I work for, before I joined, ran the fortran code through a utility to "upgrade" it from F77 to F95.A small part of thecode had even beenmodernised into modules, it is an ongoing process.

This made me think. Another possible problem area might be argument mismatches.
Some scripting work I did for our codehelped us find lots of argument mismatches especially integer*2 to integer*4 (We have been increasing the size of the models our programs can handle).
Depending on the volume of your code how easy would it be for you to put as much as possible into modules? Or you could always use the Projects->Fortran->External Procedures-> Generate Interface Blocks and the Diagnostics->Check Routine Interfaces options, certainly in the Debug build which would help withfiles within the same directory.

You didn't say whether the Debugexe gave the same results as the Release exe.

Les