3

According to the Fortran standards,

If the STAT= specifier appears, successful execution of the ALLOCATE statement causes the stat-variable to become defined with a value of zero. If an error condition occurs during the execution of the ALLOCATE statement, the stat-variable becomes defined with a processor-dependent positive integer value...

So far so good. However, it happens that modern operative systems tend to use delayed memory allocation, i.e. no error condition is raised when the ALLOCATE statement is executed. The program goes on, but when the exceeding memory is required, it crashes.

I thought that using the source statement in the allocation could allow to retain control of the memory but, at least trying on my MacBook Pro with gfortran, it does not work. Is there any workaround or we should renounce to keep control on memory management?

GiorgioP-DoomsdayClockIsAt-90
  • 425
  • 6
  • 13
  • 3
    No, this is beyond Fortran. There is nothing you can do even in C with access system functions. We might have a duplicate. – Vladimir F Героям слава May 09 '21 at 11:18
  • 1
    Related https://stackoverflow.com/questions/32701025/why-can-fortran-allocate-such-large-arrays https://stackoverflow.com/questions/864416/are-some-allocators-lazy – Vladimir F Героям слава May 09 '21 at 11:21
  • 1
    And, of course, `source=` has nothing to do with this. It just says what array you are copying. – Vladimir F Героям слава May 09 '21 at 11:22
  • I know that the issue of delayed allocation goes beyond Fortran. However, once the maybe overbooked allocated memory is *used* in the same ALLOCATE statement with the source=... copying and a STAT=... is used, I think that the behavior could be different from an abrupt killing of the process. And this is a Fortran issue. You may say that this is the way the standard goes. I am asking if there is anything else one can do besides waiting for a new feature in the Standard. – GiorgioP-DoomsdayClockIsAt-90 May 09 '21 at 11:43
  • 2
    It's not a Fortran issue. ALLOCATE can only detect whether the operating system reported an error during the call to allocate memory. If that succeeded, but the OS later decides that the allocated memory can't be accessed, there's nothing Fortran can do. You could investigate whether the OS provides access to more control using calls directly to its API, but that would mean bypassing ALLOCATE/DEALLOCATE. – Steve Lionel May 09 '21 at 16:14
  • 1
    @SteveLionel I understand your point. However, if the Standard still contains the sentence I quoted (I have copied from the last draft before publication), it is written: "if an error occurs **during the execution of the ALLOCATE statement**". Not "during the allocation of memory". Is the *source=* not part of the Fortran ALLOCATE statement? At least it seems ambiguous to me. – GiorgioP-DoomsdayClockIsAt-90 May 09 '21 at 17:14
  • @GiorgioP, I gather you would kike STAT (or ERRMSG) to reflect the "assignment" of SOURCE to the allocated memory. The standard doesn't require that - it says, "The set of error conditions for an ALLOCATE statement is processor dependent." In practical terms, the memory allocation is done, with any error reporting, then the compiled code transfers the value of SOURCE to the allocated storage (and sets the dynamic type if polymorphic.) If this action triggers a segfault, there isn't a lot that can be done about it. – Steve Lionel May 09 '21 at 23:16
  • 1
    @SteveLionel ok, what you say means that in the case of delayed allocation, the stat= feature is basically useless. I think this is something that should be stressed in the current textbooks, and even in the Standard, while this is usually not the case. – GiorgioP-DoomsdayClockIsAt-90 May 09 '21 at 23:33
  • 1
    Yes, unfortunately currently "the stat= feature is basically useless". This is a real pity for scientific applications. – Ian Bush May 10 '21 at 11:16
  • 2
    I would not say stat= is useless, but you're correct that in this particular situation it may not help you. Personally, I consider the notion of delayed allocation to be a mis-feature. It offends my sensibilities as a former OS developer in that the OS is lying to you. – Steve Lionel May 10 '21 at 17:51
  • 1
    @SteveLionel seconded. As an applications developer it offends my sensibilities by making it all but impossible to write robust code. – Ian Bush May 10 '21 at 22:10

0 Answers0