On Asynchronous I/O, are the results of IOSTAT and/or IOMSG returned asynchronously (when the I/O completes) or at the point of READ/WRITE?
IOW is there a lifetime requirement of the target variables to be available during the lifetime of the I/O?
Definition of the variables nominated by IOSTAT or IOMSG happens during the execution of the relevant statement with the IOSTAT or IOMSG specifier, not "in between" the statements that initiate and wait on transfers. Unlike the items in the input/output list, there is no requirement on the lifetime of the variables specified by IOSTAT or IOMSG. See F2018 22.214.171.124p7 in particular.
The reason I ask is from observance
subroutine A ... call B subroutine B ... character(len=256) :: ioMSG integer :: ioStat ... read(inUnit, ASYNCHRONOUS='YES', END=100, ERR=200, IOMSG=ioMSG, IOSTAT=ioStat) array return 100 call DOSTOP("END myReadTemp"//ioMSG) 200 call DOSTOP("ERR myReadTemp"//ioMSG) end subroutine B ...(back in A) wait(inUnit) ! stack occasionaly gets corrupted
The particular problem (stack check reports corruption) occurs when subroutine A is within a parallel region (and as a result B is executing within a parallel region). My (unfounded) assumption is the read is storing the addresses of ioMSG and ioStat for potential future use upon I/O completion. IIF that is the case, then the stack would get corrupted (as B goes out of scope prior to I/O completion).
This problem is intermittent. When running with OMP_NUM_THREADS=1, the problem does not appear. If I vary the amount of stack, the problem moves around.
I am aware that I can obtain at wait(u) as well as via INQUIRE.
Now then, I moved the ioMSG and ioStat to within a module data space and this resolved the stack corruption issue.
Note, this is not stack overflow, rather in debug mode, chkstk is called to check signature bytes surrounding the stack frame. These get (got) clobbered.