Re: Fortran based MEX w/ COMMON/SAVE

Duane Bozarth wrote:
> Doesn't seem like the memory associated w/ array dat would ever get
> released...
I'm not sure about this. I believe dat (pointer to the array) and the
area it points to should "stay alive" as this becomes LHS, an output
from MEX file. Anyway, I tried to release that memory w/ mxFree and
it did what I expected, on output from MEX it either lead to the
fatal straightaway, or it pointed to nonsense and caused fatal a bit
later.

> No idea what actually causes the error as it is non-specific.
> Sounds as
> though it's a Windows resources thingy????
.... me as well. The thing is that after each call and subsequent e.g.
"clear my_mex_file_name" not everything seems to be removed according
to the Task Manager (a rough indicator), e.g. some cca 90KB per call,
and when trying the 23rd call a runtime error is issued and Matlab is
closed.

> Well, since that's what you've asked the compiler to do by using
> SAVE
> (and the structure of the code probably requires it for successful
> operation)
Yes, it does.

> I don't know that one should be surprised...
Well, I was. It's 20 years old code and the concept of working w/
SAVE at the begining of each subroutine is a bit unusual to me.

> COMMON data stay in scope over the lifetime of all areas of code
> that
> refer to the COMMON named. W/O the Fortran startup code I'm not
> sure
> that there is an effective way to absolutely ensure the OS gets a
> chance
> to unload it if there isn't a Fortran END or STOP statement.
This is a very good point. The original code had structure:
PROGRAM ...
SAVE
INCLUDE common_block_files
...
calls to other SUBROUTINEs (each w/ SAVE)
...
format statements
END

I simply changed it to:
SUBROUTINE ...(my_arguments)
...
calls to other SUBROUTINEs (each w/ SAVE)
...
my_argument preparation
RETURN
format statements
END

I appreciate that this may not be "fair" to the OS management and
probably too simplistic. However, this was the first quick choice
influenced by the level of my knowledge (or rather ignorance) of
Fortran internal working and also expectation of the problems
elsewhere (2 languages C/Fortran, 2 compilers LCC/GCC (now only GCC),
interaction w/ Matlab). Moreover, it seemed to work, only later I
found this runtime error.

Can you comment more on the above change of the structure of the
Fortran code (changing PROGRAM to SUBROUTINE)? Or alternatively, have
you got any pointers to look into to find out more about what's
actually behind the scene when I do this modification?

> There's no connection between the Fortran I/O unit numbers and
> Matlab
> file handles so there's no reason to think fclose() has any bearing
> on
> them whatsoever.
Well, it was only my guess.

> If you have data files containing needed output, it's probably
> risky to
> assume that w/o a Fortran CLOSE statement being executed that all
> data
> will be flushed and written to the file. Sounds like you would
> need to
> track these down and add appropriate CLOSE statements to ensure
> this.
The code was patched over many years and many people added their I/O
files, maybe for diagnostics, maybe for meaningful output or just to
keep data while looping, I don't know. It is not documented, the only
thing I see is that when it runs
it produces maybe 10-20 units, at the end of original PROGRAM most of
then are removed (maybe thanks to proper END at the end of PROGRAM
section). Anyway, the main output file is properly CLOSEed and it
"lives" without problems after PROGRAM termination. My MEX
modification, most likely due to the change in the structure of the
code (see above), creates the same files/units, but these are not
removed on return of the control to Matlab from MEX file (maybe due
to the placement of RETURN before END in the main SUBROUTINE,
originally main PROGRAM).

Is it allowed to place END before RETURN in SUBROUTINE to ensure all
PROGRAM-like terminating actions, or is there any alternative way how
to do it?

> Also, a clean STOP or END to the Fortran routine would probably go
> a
> long way towards cleaning up the rest.
I'll try this out in a day or two and report on success/failure.

Anyway, thanks very much for helpful hints/advice.

Brano
.

Relevant Pages

  • Re: Fortran based MEX w/ COMMON/SAVE
    ... >> Doesn't seem like the memory associated w/ array dat would ever get ... > SAVE at the begining of each subroutine is a bit unusual to me. ... W/O the Fortran startup code I'm not ... > interaction w/ Matlab). ...
    (comp.soft-sys.matlab)
  • Re: printing a pointer in fortran
    ... A fortran pointer isn't a C pointer. ... integer counter, iterations ... subroutine shuffle ...
    (comp.lang.fortran)
  • c++ calling fortran and fortran calling C++
    ... I need to call a subtroutine in fortran. ... This subroutine must call a function of my program. ... pointer of my function but I have segmentation fault. ... c number of non-space characters (embedded spaces are ...
    (comp.lang.fortran)
  • Re: passing an unknown number of parameters of unknown type
    ... So, basically, a subroutine that accepts a function as an argument ... I want the optimization subroutine to be general ... One is something a bit like what Matlab can do with optional arguments, where not only can the number of arguments be optional, but variations in type can results in completely different argument lists to the same function. ... The nearest you can come to that in Fortran is ENTRY, which isn't much used nowadays but still exists in the language. ...
    (comp.lang.fortran)
  • How to link the FORTRAN 77 to MATLAB graphic tools
    ... I'm facing the problem on how to link the Fortran 77 to Matlab ... graphics tools in the MATLAB. ... a small subroutine to link my existing Fortran source code to Matlab ...
    (comp.soft-sys.matlab)