forums.silverfrost.com

[MattMcD]

Got this Error whilst debugging a rather large program
Would be grateful for a more verbose description than "A function called from within an I/O statement has itself performed an I/O" So I can try to debug it

Many Thanks

Matt

[sparge]

Build a debug version and run it under control of sdbg, and it will identify the problematic line of source code for you

[MattMcD]

I've tried that,
it points to a function that I've written,heres the code, (with comments of stuff I've tried) (note bolded line is where the error occurs)

real function HXA(h,i,d,n)
!Calculates number of expected occupies of available housing
integer, intent(in) :: h,i,d,n
! real,external :: HXN,HXV
real :: summa
integer :: v

summa=0.0
do v = 1,mxdm
if (ldfdm(JISDM,v)) then
write(6,'(a3,1x,e15.6)')'HXN',HXN(v,h,i,d,n)
write(6,'(a3,1x,e15.6)')'sum',summa
summa = summa + HXN(v,h,i,d,n)
else
! Invalid Development process
end if
end do
write(6,'(a3,1x,e15.6)')'HXA',summa
HXA = summa + HXV(h,i,d,n)
end function HXA

and here is HXN


real function HXN(v,h,i,d,n)
!Calculates Number of eXpected Occupants of new Dwellings
integer,intent(in):: v,h,i,d,n
real :: summ
integer :: ar,avtemp

summ=0.0

do avtemp = 1, mxav
if (ldfavag(avtemp,hhldag)) then
summ=summ+AvArMb(avtemp,i)+AvArPl(avtemp,i)
!Note Number of Pool and Mobile House are not given by tenure and dwell type
end if
end do
! write(6,'(a6,f15.6)')'New - ',NNEWDwells(v,d,n,i)
! write(6,'(a6,f15.6)')'MbPl- ',(avarMb(h,i)+avarpl(h,i))
! write(6,'(a6,f15.6)')'NTS - ',(modopt(JMOPTMHTS)*Summ)
! write(6,'(a6,f15.6)')'HXN - ',(NNEWDwells(v,d,n,i)*(avarMb(h,i)+avarpl(h,i))/(modopt(JMOPTMHTS)*Summ))
HXN = NNEWDwells(v,d,n,i)*(avarMb(h,i)+avarpl(h,i))/(modopt(JMOPTMHTS)*Summ)

end function HXN

[sparge]

Hmmm. Seems OK at a first glance. Though I see that I/O in the function has been commented out. And you said it's a rather large program. Is it possible you didn't rebuild correctly after you commented out the I/O lines?

[Robert]

Try:

[MattMcD]

I removed the comment from the I/O
(ie real,external :: HXN,HXV)
and it now claims that HXN is a missing function, when its actually in the same module...
hard to misspell HXN too
your suggestion causes it to hang when tmp is assigned, but I guess thats what we expected...

[sparge]

[MattMcD]

Well the output to the screen(or unit 6) in HXN is an old attempt to further narrow the problem in this instance, where it hung on

write(6,'(a6,f15.6)')'New - ',NNEWDwells(v,d,n,i)

where NNewDwells is an array, which is initalised to 0 and definetly defined in the debugger on crash...

[sparge]

Well, that would have been a function called from within an I/O statement itself performing an I/O, wouldn't it? So it would have compounded the problem, not narrowed it.

What about the possibility that the rather large program is not getting rebuilt correctly? I think the error message is very clear. And if the function HXN is being reported as missing when it's in the same module (as what, by the way?), it definitely sounds to me like you should be ruling out build issues in the first instance.

[MattMcD]

Well I'm fairly sure I've built it correctly:
Removed all the existing object and module files
Used the makefile that works for the other files

What exactly constitutes I/O?
Read/Print/write?

[PaulLaidler]

The key to this is in Robert's comment.

You cannot write

write(6,'(a3,1x,e15.6)')'HXN',HXN(v,h,i,d,n)

if the function call to HXN contains WRITE statements (FTN95 does not allow you to do this).

You must separate out the call to HXN into a separate statement.
OK the WRITE statements have apparently been commented out but this is the essence of the problem.

[sparge]

I've never used a makefile, so I can't really comment - except when you say it "works for the other files", I don't know what you mean by that. You're not just using files, you're using modules, and the compilation process is more complicated than for a set of independent files, because order matters. It sounds like you're not using Plato - I'd recommend that as a useful precursor step.

[DanRRight]

i've got the same annoying with occasional crash problem recently within the heavily "Clearwin"ed code despite i am aware that write(*,*) ABC(A,B,C)
where function ABC itself performs the write is forbidden, so there is no such statements in the code. Besides the code may work for hours ok, then crash with that error 410.

My write performs internal write into character variable charABC like that
write(charABC,'(i7)') i

Or crash happens on internal read(charABC,'(i7)')j2...Debugger is of course saying me nothing why it happening, everything seems valid.

All that takes place in the %gr[full_mouse_input] part of the code when i wiggle mouse over the screen and do draw_character@(charABC) on it. And I of course take care that i lock execution of the body of the callback function until previous call to it is completely finished. Fun is also i have almost not done anything with the code during this week when error started to surface...

I suspect when i wiggle mouse the full_mouse_input I/O somehow overlaps in time with the regular WRITEs which are permanently going into several %cw windows. Full_mouse_input clearly makes the out of order flow of the fortran code when the mouse is wiggled and appropriate callbacks with I/O are executed. Until now though i have not succeeded to reproduce this specific error 410 in a small sample code

The common sense workaround like
write(charABC,'(i7)',err=123) i
does not work. Why not? at least the code by missing one write and reporting it would not crash....

This error 410 started to appear in FTN77/95 around 2000-2002 immediately after some compiler upgrade, before i never ever experienced it. And decently i have no clue why Error 410 is an issue for internal writes into character variable even if some other writes take place outside it -- they are completely not related writes...i dunno, may be i got some terrible bug or overclocked computer is again out of mind, i showed here couple such crazy examples before

So how easiest way to remove this error using kind of yield or lock command (forgot exact syntax) without turning the whole code into multi-threaded code? Or this question to developers: may be it is possible to implement crash resistance by allowing in this case for read/write I/O to have error handling usual way (if error - go to specified label)?

Crashes are so DOSsish. All get immediately sick from any software when it crashes, i'd say crashes are unacceptable. They are better of course then the whole computer gets BSOD, but still they are next in "badness". Fortran has to have utilities to handle that. Fortran as the most mature and strict language compared to all other languages has the chance to be the most error resistant so that people will write heart controllers using it.

[DanRRight]

After some research on this matter i found that what seems happening right now is that this kind of so called recursive I/O with internal write into character variable was cleared in F2003 as legitimate. Why it was not allowed before during 50 years is beyond me. This is probably how quick Fortran Standard Committee works. Hence this code has to work with no problem, and is claimed as working in many compilers including some older F77 ones (Sun)

[DanRRight]

Thinking about how Windows and Clearwin operate, i am almost convinced that without solving the problem of recursive I/O Clearwin programs will be inevitably crash prone. It is in the nature of Windows to create out-of-order processes (just by clicking on the project possible windows and launch several processes) which will always conflict with each others that way. Some kind of error handling like

write(ch_i,'(i9)',err=1000)i

is clearly needed