Debug "step into" to nowhere

[Mathieu_L_]

Hi there,

I'm trying to debug an old code (see previous post). I'm going step by step with the debugger. At the end of a Subroutine the code goes normally as:

...

RETURN

END

When the cursor is on the END statement and I push the "step into" command, then the cursor disapears. A second push on the "step into" button will crash the application. What's appening in the END statement? Where should I look for the problem?

Thanks a lot for your help!

Mathieu

[Steven_L_Intel1]

You'd need to show us an actual program that demonstrates this. There can be some "cleanup" code at the end of a routine, doing things such as deallocation of local allocatables, etc. Step Into can often put you in library code unexpectedly. I would not expect a crash, though, unless your program had previously corrupted the stack.

[Mathieu_L_]

Here are the files.

SSARR.zip includes the solution.

S_test.zip must be placed in C:\ for more convenience.

Upon starting the program, it will print : "File IODC does not exist. ENTER DOS NAME OF SSARR WORK FILE".

Just enters location of IODC file in S_test. I'm not sure if it allows long names, that why I'm suggesting putting it in C:\. So C:\S_test\IODC...

Then it will crash at the end of init.FOR (or after IAINIT call in SSARR.FOR).

Thanks!

[Steven_L_Intel1]

You didn't include the sources you're using for this. I assume you made edits from the downloaded version.

[Mathieu_L_]

Oh.. sorry about that (and about the delay, I was a little bit mixed up with my files). Here are the sources... Yes, I made some little changes, but nothing that affects the code or declaration of variables.

Thanks again.

[Mathieu_L_]

Have having some trouble posting the source files... Is it working?

[Mathieu_L_]

I'll be out of the office for holidays. Seasons greetings to all of you. See you in January!

[Steven_L_Intel1]

I'll repeat my assessment that this is a poorly written program, though it's representative of a lot of 1970s code. I've found one serious bug so far, plus an assumption that is no longer valid. There may be other issues.

The serious bug is in routine INIT (INIT.FOR). INIT calls CDATE, passing the variable IDA. CDATE receives IDA as IDATE, which it declares as an array of five integers. But in INIT, IDA is undeclared, so it is implicitly an integer scalar. This causes memory to be corrupted when CDATE stores into the IDATE array.

The assumption relates to the calls to GETDAT and GETTIM in BTINIT.FOR. The arguments, including NSY, are declared INTEGER*2, but in our implementation these routines expect the arguments to be INTEGER*4, so when the results are stored, memory is corrupted. This can be fixed either by changing the declaration to be INTEGER*4 or by adding USE IFPORT just after the SUBROUTINE line - this brings in declarations that allow for INTEGER*2 arguments.

I stopped here - I'm sure there are many more issues.