Memory leakage

Memory leakage

[James Squire]

My impression is that in Ada 95 it should not be possible to have memory
leaks, but I'm not so sure.  I suspect it is a lot more difficult, but
is it indeed impossible?

As for tools help track down memory leaks, I can only find Plummer and
possibly Rational's Purify (does it support Ada?).  Are there any
others?
-- 
James Squire             Send my Spam to mailto:webmaster@cyberpromo.com
MDA^H^H^HBoeing St. Louis                          http://www.boeing.com
Opinions expressed here are my own and NOT my company's
------------------------------------------------------------------------
"Back on Earth I heard things.  The kind of things you're not supposed
to
 hear about.  Genetic manipulation, breeding telepaths against their
will,
 so called relocation camps for rogue telepaths that aren't much better
 than concentration camps."
	-- Dr. Franklin, "A Race Through Dark Places"

Re: Memory leakage

[Ted Dennison]

In article <39D8CD62.7B6EB2D4@boeing.com>,
  James Squire <james.a.squire@boeing.com> wrote:
> My impression is that in Ada 95 it should not be possible to have
> memory leaks, but I'm not so sure.  I suspect it is a lot more
> difficult, but is it indeed impossible?

You suspect correctly. It is quite easy to produce memory leaks in Ada,
if you really want to. All you have to do is use "new", and not ever
use Unchecked_Deallocation. But the language does try to make it harder
to do on accident.

The main issue is you just don't need to use "new" all that much.


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Memory leakage

[Marin David Condic]

James Squire wrote:

> My impression is that in Ada 95 it should not be possible to have memory
> leaks, but I'm not so sure.  I suspect it is a lot more difficult, but
> is it indeed impossible?

It is certainly a lot less likely than in C/C++ for a lot of reasons - not
the least of which is that in Ada, you don't go grabbing pointers to
everything in sight, like you have to in C/C++. However it is not at all
impossible. Say you built a linked list package that lives at the Library
level. If you messed up and didn't recover memory as you deleted nodes,
you've got no language guarantee that the memory won't be floating around
forever, completely inaccessible. Of course, when the program terminates,
the memory ought to be recovered at that stage, but that's rather pointless
to consider as a form of garbage collection.

OTOH, if your usage is *not* at the library package level - perhaps within
the scope of some procedure - you will reclaim that memory when you leave
the scope. But thats not the way most dynamic things are done.

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Memory leakage

[Keith Thompson]

Ted Dennison <dennison@telepath.com> writes:
[...]
> I do seem to remember an issue with tasks having to keep data about
> themselves around after they terminate (perhaps for the 'terminated
> attribute?).

My memory of that issue is almost as vague as yours, but a bit
lower-level.

TeleSoft's Ada-83 compiler implemented a task object a pointer to a
TCB (Task Control Block, a record defined in the Ada runtime library).
Normally, when a task terminated, the implementation would be able to
free the TCB and set the pointer to null.  But there was some obscure
requirement that made it necessary to keep the TCB around, just in
case the program queried a particular attribute.  As I recall, this
requirement was modified in Ada 95; it may even have been fixed in an
Ada 83 interpretation.  (Probably an "interpretation" along the lines
of "the word 'is' is to be interpreted as 'is not'".)

I'll be mildly surprised if there isn't at least one major error in
the above description.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Memory leakage

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

In article <8rfpa8$s5d$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> "Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
3A0230E5.E666B9B8@telepath.com...
> > I do seem to remember an issue with tasks having to keep data about
> > themselves around after they terminate (perhaps for the 'terminated
> > attribute?).
> >
> This was due to the so-called (hmm) Rosen Pathology in Ada83. It has
> been exterminated in Ada 95.

Good. It sounds nasty. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Memory leakage

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]


"Ted Dennison" <dennison@telepath.com> a �crit dans le message news: 3A0230E5.E666B9B8@telepath.com...
> I do seem to remember an issue with tasks having to keep data about
> themselves around after they terminate (perhaps for the 'terminated
> attribute?).
>
This was due to the so-called (hmm) Rosen Pathology in Ada83. It has been exterminated in Ada 95.

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Memory leakage

[Ted Dennison]

Robert Dewar wrote:

> In article <8rapg8$66b$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
>
> > You suspect correctly. It is quite easy to produce memory
> leaks in Ada,
> > if you really want to. All you have to do is use "new", and
> not ever
> > use Unchecked_Deallocation.
>
> That missed the point of the question, it is not a memory
> leak in language terms to allocate and never free using
> appropriate statements in the language, this is simply
> doing what you are asked to, and the only thing that makes
> it a leak is intent.

You cut the original question, which to me is quite clear that it is
talking about the possibility of having memory leaks in an Ada95
program. Here it is again:

> My impression is that in Ada 95 it should not be possible to have
memory leaks, but I'm not so sure.

The source (user mistakes vs. language problems) was not mentioned.
Therefore both should be assumed to be under discussion. Perhaps I did
misread the poster's intent as you suggest, but its certainly not clear
that I did!

I know it sounds like a silly question to a lot of experts. But I have
encountered lots of folks before who have heard this sillyness about
Ada; that its somehow immune to memory leaks. I've also heard the
opposite fantasy: that it somehow leaks memory just by existing on your
hard-drive. If someone comes here questioning one of these views, we
should certainly be ready to address it, no matter how silly of an idea
it is.

Not that what you are talking about is a invalid realm of discussion
either. But if you would *prefer* to talk about that, just come out and
say so. We won't hold it against you. :-)

> The question was whether using constructs in the language
> you can get leaks, and the answer should be no.

I do seem to remember an issue with tasks having to keep data about
themselves around after they terminate (perhaps for the 'terminated
attribute?).

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Memory leakage

[Robert Dewar]

In article <8rapg8$66b$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> You suspect correctly. It is quite easy to produce memory
leaks in Ada,
> if you really want to. All you have to do is use "new", and
not ever
> use Unchecked_Deallocation.


That missed the point of the question, it is not a memory
leak in language terms to allocate and never free using
appropriate statements in the language, this is simply
doing what you are asked to, and the only thing that makes
it a leak is intent.

The question was whether using constructs in the language
you can get leaks, and the answer should be no.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Memory leakage

[Ed Falis]

Ted Dennison wrote:
> In article <8rfpa8$s5d$1@wanadoo.fr>,
>   "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>> This was due to the so-called (hmm) Rosen Pathology in Ada83. It has
>> been exterminated in Ada 95.
>
> Good. It sounds nasty. :-)

It was, but presented new and interesting evidence that the software
motto "anything can be solved with an additional indirection" is true.
;-)

- Ed

Re: Memory leakage

[Robert Dewar]

In article <3A0230E5.E666B9B8@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> You cut the original question, which to me is quite clear that
> it is talking about the possibility of having memory leaks in
> an Ada95 program.

I think you miss my point. It is of course possible to write
a program that uses more and more memory and never returns it.
Indeed it is hard to imagine ANY reasonably expressive language
that does not have this property -- note that it is perfectly
possible to create such a program in Java.

If one creates such a program, is it a memory leak? Well from
a purely semantic point of view, one cannot say, since it
depends on whether the programmer intended that the program
behave in this manner.

So there are two questions one can ask:

1) Is the language+implementation free of *inherent* leaks
i.e. leaks that do not relate to specific programmed use of
memory, but are incidental to the implementation. An example
would be a poor implementation of unbounded strings that did
not satisfy the RM requirement of automatic reclamation of
this data, or a tasking implementation that left some storage
behind each time a task terminated or ...

It the intention of the Ada 95 design that a correct
implementation of Ada 95 be free of such leaks.

2) Is the language designed in such a manner that the creation
of programs that constantly increase their memory usage but do
not intend to do so is unlikely?

Well this is of course a far more subjective issue, and most
certainly I do not consider that the original question can
possibly be asking this question, since it talked of such
leaks being impossible, which is of course the wrong kind of
language to use when discussing point 2). One can only talk
of more or less likely.

This is a very important distinction, so I trust it is clear!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Memory leakage

[John McCabe]

James Squire <james.a.squire@boeing.com> wrote:

>My impression is that in Ada 95 it should not be possible to have memory
>leaks, but I'm not so sure.  I suspect it is a lot more difficult, but
>is it indeed impossible?

It's dead easy - especially if, when you first start using access
types heavily, you forget that Ada doesn't have a garbage collector to
mop up all the dross you've left behind.

>As for tools help track down memory leaks, I can only find Plummer and
>possibly Rational's Purify (does it support Ada?).  Are there any
>others?

On Solaris, try

df -k /tmp

If the swap space size is gradually decreasing (not just the free
stuff, the actual overall area) then you've probably got a memory
leak.


Best Regards
John McCabe <john@assen.demon.co.uk>