fortran system halts on return from function call, no error code given

[stbernard]

I have been porting an old FORTRAN system from HP Unix to windows ifort. It is 95% complete at this point(does successfully most of what it is asked to do). I have hit a problem where a function is called. The function is about to return to its caller. It returns an integer, and via a print just before the return statement, I can see that the return value would be '0', i.e, good.That is, I actually do a printfdisplaying the function name, which is the integer that would be returned. But instead of returning, the entire fortran system just shuts down, with no error messages of any kind, even though I have traceback on, and have been able to see call chains when things such as divide by 0 have occurred.

Is this a known bug? Is there something I should be doing diagnostically that I am not doing?

I am compiling with the following flags:

FFLGS= -nologo -c -Qzero -Qsave -Qvc8 -Od -Z7 \\

-MD -extend-source -assume:byterecl \\

-iface:default -iface:nomixed_str_len_arg -convert:big_endian \\

-traceback -fpe:0 -fpp -fpscomp:logicals -nopdbfile -debug:full \\

-DUPPERCASE -DWIN -DWIN32X_9 -DGEDevSuite3 -DDS3 -I../includes

[TimP]

-warn-interfaces should catch inconsistencies between caller and callee.
If you're porting from Unix, I don't see why you would use fpscomp options.
Does Qvc8 match your Visual Studio? I'm not sure it's supported any longer.
Could you work with the default -MT rather than -MD, at least until it's working?

[stbernard]

another internal system was linked together with this for the PC, which may be the source of some of the compile options. Is now being thought to possibly be a memory leak of some kind. Will also look at these compiler suggestions, thanks.

[GVautier]

Hello

Are you doing something like that?

Function test()
test=0
write(*,*)test
end function

write(*,*)test()


If so, it will crash because you can't invoke write (inside the test function) in a write statement.

[jeremy_h]

I saw behavior very similar to this while porting a mixed language application from VS6. A C routine was corrupting the stack (a strcpy length error), which, for some reason, CVF did not care about but it crashed IVF. Perhaps one of your custom linked libs is doing something that bothers IVF.

Also, a long shot, I saw examples of calling convention problems brought forward by the migration wizard. For instance, we changed from stdcall to cref, and if an author had explicitly set the calling convention to stdcall (rather than inherit) then these became bugs in the migrated code. A calling convention mix-up could account for your problem.

[stbernard]

I put some diagnostic printf's in, but there were no pre-existing writes. There is a smidgen of C code in the system but it is not involved here. Did not use any wizards in this. Thanks for your inputs here.

[GVautier]

So, if no obvious problem exists, the most certain cause is a stack corruption elsewhere in the program caused by a write out of the bounds of an array (or a string).

For example :

subroutine test(string)
character*80 test
test=" "
end subroutine

character*10 string
call test(string)

Use only charatcter*(*) for character arguments

For arrays you must check the source beginning at the point where it crashes.

You can also try in debug mode but it changes the stack so the problem may not ocurs.

Good luck