Error when writing to a file from a child window

[reidar]

I am migrating a QW CVF application to QW IVF. The program has a main window with a menu. So  when selecting a menu item, an accompanying child window will be opened. The program can perform several calculations and the results are written on the screen (UNIT 13) and in addition the results are dumped to a text file (UNIT 7) for documentation purposes. However, unlike to CVF, the program does not accept a second unit.

If the child window ( 13) is opened first, the program fails to write data to the text file, unit 7 and vice versa. Please take a look at the attachment for more details.

Can anyone give me a tip ?

[mecej4]

The key point to note is the phrase "Recursive I/O" in the error. I suspect that the function FRQ, which is used in an I/O list in your screenshots, itself does I/O to the file.

Assign the value of FRQ(..) to a temporary variable, and place that variable in the I/O list instead of FRQ().

[reidar]

Mecej4, thank you for response !

The FRQ is just an one-dimensional array, holding the calculated eigen-frequencies..

And again, the program comes from CVF and worked well... also the CVF version of the program runs pretty well in my Win7 computer. 

[jimdempseyatthecove]

The error is occurring on unit IDEP
The error message is "recursive I/O"
If the above is due to recursive I/O, as opposed to program getting trashed (index out of bounds, uninitialized variable, ...)

In the routine where the error occurs insert a sanity check ASSERT

integer, save :: IrecurseLevel = 0
...
if(IrecurseLevel .ne. 0) then
   print *,"Place breakpoint here"
endif
IrecurseLevel = IrecurseLevel + 1
! first use of I/O to IDEP
CALL npage(IDEP)
...
WRITE(IDEP,93)
! above is last I/O to IDEP
IrecurseLevel = IrecurseLevel -1

You may need to insert additional sanity checks along the above following line of thought.

Note: First assure that the program builds with all compiler diagnostics enabled, and all runtime checks enabled.

Jim Dempsey

[andrew_4619]

Long time since I did quickwin but is it one of those focusqq problems? I would read the help.  You need to set focus for the main or child maybe before the writes. When you open the child I recall it gets the focus automatically and then maybe this new thread is trying to write to the already open file from the main thread and thus tries to open it again?

[reidar]

Than you all for feedback

jimdempseyatthecove, remember what I wrote, if I interchange the open - statements, the error occurs when writing to unit IDEV, the screen. So it seems to me that, only, and only the last assigned unit is accepted. Anyway, if you write to an unassigned file, let's say unit 77. Then I would expect to find the output at fort.077.  However I will test your proposal as well.

[reidar]

I set the Fortran runtime property to

Generate trace back to :Yes (/traceback)

Default carriage control to: Fortran (/ccdefault:fortran)

Run time check to:All (/check:all)

With that settings the program runs, however I message box from VS pops up telling:

Run-Time Check Failure #2 - Stack around the variable '_CHARPACK_2' was corrupted.

What does it mean? I have no named variable  CHARPACK in the program..

[mecej4]

The indications are that some part of your code or the RTL is writing to portions of memory that it should not. As a result, the stack is corrupted and the error recovery mechanisms have been damaged. In such situations, do not take the reported error message literally. If the RTL could, it would have done better to say, "I'm lost, I don't know what to say!".

Isolate the portion of code where the error occurs. You may have to remove portions of your code to do this. For example, if you remove the Qwin parts, does the error still occur? Is the bug consistent and repeatable? If not, hunting it down is harder.

[jimdempseyatthecove]

It is not unusual for old CVF programs to have used Cray Pointers. If you use an uninitialized pointer, or a pointer that becomes invalid after initialization it can cause memory corruption.

It also appears (#7) that you have not performed the compile time /warn:interfaces this will catch missing and/or improper arguments on CALL and function calls (which can also corrupt memory).

Jim Dempsey

[reidar]

I compiled with  /warn:interface but received no messages.. However maybe  conflicting stings caused problems and overflow as hinted by mecej4. I/O works fine, thank you all for feedback!