Once again...

jwe0019i-u The program was terminated abnormally with Exception Code
EXCEPTION_ACCESS_VIOLATION.
Error occurs at _free
Called from or near line 461 of _newturb_
Called from or near line 346 of _MAIN__
error summary (Fortran)
error number  error level  error count
jwe0019i         u           1
total error count = 1

I'm still puzzled by the error msg. listed above, especially I would like
to know, what's the meaning of 'Error occurs at _free'. There is no routine
called '_free' in my code. Line 461 ist the end statement of subroutine
newturb.

Compiling with -chkglobal switched on yields exactly the same message.

Compiler is Lahey LF95 5.6h, OS Windows XP Pro

Any ideas, anyone?

Squirrel wrote:
> jwe0019i-u The program was terminated abnormally with Exception Code
> EXCEPTION_ACCESS_VIOLATION.
>  Error occurs at _free
>  Called from or near line 461 of _newturb_
>  Called from or near line 346 of _MAIN__
> error summary (Fortran)
> error number  error level  error count
>   jwe0019i         u           1
> total error count = 1
>
> I'm still puzzled by the error msg. listed above, especially I would like
> to know, what's the meaning of 'Error occurs at _free'. There is no routin
e
> called '_free' in my code. Line 461 ist the end statement of subroutine
> newturb.
>
> Compiling with -chkglobal switched on yields exactly the same message.
>
> Compiler is Lahey LF95 5.6h, OS Windows XP Pro
>
> Any ideas, anyone?

1. Contact Lahey support, report your problem
2. Check your code using another compiler
(Intel fortran, ftn95) - free trials

B52B

Squirrel wrote:
>
> jwe0019i-u The program was terminated abnormally with Exception Code
> EXCEPTION_ACCESS_VIOLATION.
>  Error occurs at _free
>  Called from or near line 461 of _newturb_
>  Called from or near line 346 of _MAIN__
> error summary (Fortran)
> error number  error level  error count
>   jwe0019i         u           1
> total error count = 1
>
> I'm still puzzled by the error msg. listed above, especially I would like
> to know, what's the meaning of 'Error occurs at _free'. There is no routin
e
> called '_free' in my code. Line 461 ist the end statement of subroutine
> newturb.

_free is undoubtedly part of the runtime...sounds like probably an
internal memory deallocation routine had a problem on subroutine
exit...you've most likely got an array indexing problem or some other
memory addressing problem.

> EXCEPTION_ACCESS_VIOLATION.
>  Error occurs at _free
>  Called from or near line 461 of _newturb_
>  Called from or near line 346 of _MAIN__

_free very likely is the routine that implements a DEALLOCATE - check
whether line 461 of NEWTURB does a DEALLOCATE or perhaps is a RETURN
statement (automatically deallocating local variables as they go out
of scope).

However, you should never see this happen, as the details of memory
allocation are, in Fortran, hidden from the programmer by the compiler
and its supporting run-time library. I dare say this points to a bug
in the compiler. Even if you DEALLOCATE something that isn't allocated,
it should behave in a better way that just throwing an access violation.
The only case I can think of off-hand where such behaviour is barely
acceptable is having an undefined pointer and trying to DEALLOCATE that
one. Even then, a quality compiler should not do this.

Jan

I tend to agree that it might be a compiler bug. What I forgot to mention
in my initial posting is that the code runs smoothly when compiled by a
later version (5.7) of Lahey LF95.

Squirrel wrote:
> I tend to agree that it might be a compiler bug. What I forgot to mention
> in my initial posting is that the code runs smoothly when compiled by a
> later version (5.7) of Lahey LF95.

Most folks would put 2 and 2 together and figure out that the vendor
had fixed a problem. The most polite comment is that it sure sounds
like a convincing argument for upgrading. Lahey provides many fixes
on their site for downloading.

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

> However, you should never see this happen, as the details of memory
> allocation are, in Fortran, hidden from the programmer by the compiler
> and its supporting run-time library. I dare say this points to a bug
> in the compiler.

I would not call this sufficient information to merit such a
conclusion.  In fact, it wouldn't have been my first guess at all.
Overwriting memory by exceeding array bounds or other programming
errors could easily cause symptoms like this.  That would have
been my first guess.

The fact (reported elsewhere in the thread) that upgrading the
compiler version made the symptoms go away is perhaps evidence
that my first guess was wrong.  (It happens.)...

But I'd still be awfully tempted to suggest turning on bounds checking
just to make sure; there is still the possibility that the bug is in
the code and that the upgrade just hid the symptoms instead of solving
the root problem.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

> I would not call this sufficient information to merit such a
> conclusion.  In fact, it wouldn't have been my first guess at all.
> Overwriting memory by exceeding array bounds or other programming
> errors could easily cause symptoms like this.

That a possibility, of course. On the other hand, I think the support
libraries should be programmed defensively, and should try not to reflect
such problems to the user in an unfiltered way, as was done here.

Jan