Error 410

Hi,

I occasionally suffer from the following error message:-

'Error 410, A function called from within an I/O statement has itself performed I/O'

I'm struggling to get to grips with the reasons for this to occur, as it doesn't appear to be an easily repeatable error.

The most recent time that this error occurred was during an OpenGL graphics repaint , which was initiated in the callback function for the OpenGL graphics using clearwin_string@('CALL_BACK_REASON') the reason being DIRTY The program was populating a character string for subsequent plotting to the screen. The line of code where the error occurred was:-

  WRITE(STRING,FORM)VAL

where VAL is a double precision real number, string is a 23 character string variable, and FORM is 9 character string variable containing the text '(F23.1) '

Does an internal write statement really count as being I/O ?

The problem usually arises with a call of the form

WRITE(,) foo(x)

where the function foo contains WRITE statements.

I do not think that the information that you give is sufficient to indicate what is going wrong in your program. Is it possible to post a small but fully working program that illlustrates the failure?

I guess that the IO is using the same buffers when writing to a string and that this is why recursive calls are not permitted.

Probably not helpful, I'm afraid, but some observations.

I've always disliked using functions to return an error or status code (like WINIO@ ! ), believing that functions should return a 'numeric value' (I include LOGICAL here) for use in some computation, and have always believed that functions shouldn't ever do I/O for precisely the reason Paul adduces above. (Subroutines can, because they cannot be used in I/O lists). However, my view is a lost cause, especially as far as Clearwin is concerned.

Now that Fortran 95 permits recursive functions, shouldn't the limitation that functions called during I/O shouldn't themselves do I/O be relaxed? It opens a can of worms, but doesn't all recursion?

I've always considered reading and writing to character expressions and the predecessor ENCODE and DECODE as 'internal I/O'. Now where did I get that expression from?

Eddie B.

Paul and Eddie,

Thanks for your replies. Unfortunately I'm not any closer to resolving the problem, as I'm not using a function with a write statement as Paul states is the normal cause of this error. And of course the program is far too large to post here ! Writing a small but fully working program would take some time, but I may have to do this to fully demonstrate the problem. All I am doing is preparing text strings for placement on the screen as part of the graphics image, in this case stress contour levels, which most of the time is trouble free. My only work around appears to be using IOSTAT=IERROR to at least stop the program from crashing. Is it possible that I am getting too many callbacks to refresh the screen image, and thus interfering with each other?

Eddie, I do understand where you are coming from, having cut my teeth using Fortran IV, however with a 'windows' gui every menu item invokes a call back to an integer function, which of course must contain or call subroutines with write statements in them ! Beyond that I use functions very sparingly, but in evaluating NURBS (Non-Uniform Rational B-Splines) with my limited maths knowledge of these beasts I found the ability of Fortran 95 to have code like 'RECURSIVE FUNCTION BLEND(I,K,T,NK,AKNOT) RESULT (BLEND_RES)' staggeringly powerful, evaluating NURBS with earlier standards of Fortran would have been a nightmare !

regards, John 😦(

I did admit that I had lost that particular crusade (beaten by the call-back function).

Any chance that your problem could be solved or lessened with more stack or heap?

I'm afraid my own code is very much in the Fortran-77 mould, and on a small scale. I am using WINAPP with the default heap and stack sizes suggested in the very first CLEARWIN example I ever saw - where the WINAPP directive needed you to specify stack and heap sizes. They seemed pretty big to me in the example (300000 and 500000). Perhaps your code could do with much more. I've struggled with the FTN95 / Plato documentation, and it looks to me as though stack and heap sizes aren't used any more. But perhaps the defaults aren't enough for what you are doing, and you need to set bigger values.

I'm not all that clear on how stack is used by Salford FTN-anything, but at one stage I was coding Assembler routines for M$ Fortran, and every time a function was called it devoured stack space ... long lists of parameters speeding up the use of stack, as the address of every parameter was pushed on it, together with the return address and much more besides. (COMMON seemed to be a device for minimising stack usage, as it reduced subprogram parameter requirements). Noting also that the executable code is often calling routines the high level programmer knows nowt about, each of which is also using the stack, presumably you could eventually run out. Is the stack space protected, or can one overflow? The DOS stack was rather small, and in effect, limited the degree of nesting of subroutine calls. I have an even sketchier idea of what the heap is for.

Apologies for a ramble, and a not particularly well-informed one at that.

Regards Eddie

[small]Eddie Bromhead wrote:[/small]

• it looks to me as though stack and heap sizes aren't used any more*

Yep, you're correct there ! I haven't used the WINAPP directive in a very long time. I use virtual common and dynamic arrays in subroutines, which makes the exe's so incredibly efficient, grabbing memory when required and releasing it when not required. Thus small models take up very little memory resources and run like greased lightning, whilst big models also run as efficiently as possible by only allocating just enough memory on demand. This is where in my opinion FTN95 is so much better than earlier standards of fortran.

So, no my problem is not a memory resource issue, but thanks for trying any way !