Re: allocatable non-dummy local variables and pointers to them

e p chandler wrote:

On Sep 27, 8:20 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:

e p chandler <e...@xxxxxxxx> wrote:


I do remember that Fortran Powerstation 4.0 did have a memory leak
problem, but I can not remember if that leak surviced process
termination. My somewhat fualty memory says that the leak persisted.


[snip]

That's much along the same vein as internal compiler errors as sometimes
discussed here. An internal compiler error *ALWAYS* counts as a compiler
bug. There might also be bugs in the code, but crashing because of code
bugs would be a compiler bug.

Likewise, memory leaks that persist past the end of an application
process would always be an OS bug. They might also reflect bugs in the
application, but the persistance would be an OS bug.

I think you misrecall. But if you do recall correctly, that would count
as an OS bug.


Yes I my memory was wrong.

As the leaking application ran on, committed memory increased as
displayed in the task manager. This, as I somehow forgot, is memory
associated with a process. When the process terminates, the memory use
does too.

I think it is possible to have an application terminate but the resources associated with the GUI (handles, widgets, windows) not be recovered. That may or may not technically be a "leak", but I'd call it a leak. There's a tool with CVF (SPY?) that lets you look at these GUI resources.



- e





- e



--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows it can't be done.

-- Henry Ford
.

Relevant Pages

  • [PATCH] fix memory leak in mm/slab.c::alloc_kmemlist() (try #2)
    ... This should fix the leak and coverity bug #589 ... Currently the only caller of alloc_kmemlistwill BUG() if alloc_kmemlist ... be leaking memory when we return -ENOMEM. ...
    (Linux-Kernel)
  • Re: allocatable non-dummy local variables and pointers to them
    ... My somewhat fualty memory says that the leak persisted. ... I recall discussion of it having memory leaks. ... would be a bug in the OS, ... but the persistance would be an OS bug. ...
    (comp.lang.fortran)
  • Re: GC.Collect can be trusted?
    ... The problem you are describing is not a real "memory leak", the problem is that you don't know who's keeping a reference to the object, so you aren't able to release the object by setting it's reference to null, this is an application bug disguised as a leak. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: allocatable non-dummy local variables and pointers to them
    ... My somewhat fualty memory says that the leak persisted. ... An internal compiler error *ALWAYS* counts as a compiler ... bugs would be a compiler bug. ... but the persistance would be an OS bug. ...
    (comp.lang.fortran)
  • Re: Matching multiple subexpressions in a regular expression
    ... so I presume the code is somehow leeking memory. ... there is a bug in ... S> either English or $& causes the memory leak. ... it is a well known ram suck but it doesn't ...
    (comp.lang.perl.misc)