Re: gawk memory leak

I wrote:
>> GC ... prevents *most* memory leaks, and
>> *most* dangling pointers, which is good, but not perfect.


In article 97-04-046, Henry Baker <hbaker@netcom.com> wrote:
>A correctly implemented GC in a conscientiously applied program of
>type hygiene solves _all_ dangling pointers, so your statement is
>incorrect.


I thought my statement would get a rise out of somebody... ;-)


It depends how you define "dangling pointer". Here's an example of a
real bug in a Lisp program (it was a compiler for some other
language). The compiler built all kinds of data structures, and
*some* of those data structures were attached to a free list when no
longer needed, and then later reused. Somebody stuck something on the
free list when they shouldn't have, which later got reused, so two
pieces of the program had their hands on something they *thought* they
had exclusive access to, causing a bug.


I would call that bug a "dangling pointer bug", because the human
thought process went wrong in *exactly* the same way that causes
dangling pointers in languages like C or Ada, when implemented as
usual, without GC -- namely, a premature "Free". (Of course, the Lisp
bug is a bit less severe, in some sense, because you can't get a
pointer to totally junk bits, which cause the program to go totally
haywire. But the Lisp program still didn't work right.)


Hence, my claim that the mere existence of GC does not prevent *all*
dangling pointer bugs. Just most of them. And you have to actually
*use* the GC by dropping garbage on the floor, rather than
circumventing it with free-lists and other by-hand allocation
techniques.


[By the way, the free list was used because the GC was too slow, or at
least the programmer thought it was. Perhaps a better, more
incremental, GC would have made the free list unnecessary, but that's
beside the point.]


>... There are systems called 'conservative' (what a misnomer!)


Indeed. I wasn't thinking about so-called conservative GC when I made
my claim -- I was just using a rather broad definition of "dangling
pointer". Here's another example: array indexes can behave like
pointers, and can dangle in the same sense. I think the broad
definition is good, for the same reason I like the broad definition of
"storage leak". After all, you can write a GC that totally prevents
100% of all storage leaks, if you define storage leaks narrowly. And
you can write a proof tool that prevents 100% of all bugs, if you
define "bug" narrowly as "disobeys formal specification", rather than
the preferable "doesn't do what it ought to".


>GC's that can under certain conditions cause dangling pointers, but
>that is because they are not 'precise' -- i.e., correctly synchronized
>to the language.


And/or not correctly synchronized to a particular compiler's
optimizations.


>... Good tools
>to track memory usage are always welcome, and can often turn up other
>kinds of 'dead bears' (silent bugs that haven't woken up and bitten
>anyone _yet_).


I've never heard the term "dead bears" in this sense. Shouldn't it be
"hibernating bears"?


I suspect that many "dead bears" actually *have* bitten someone, but
lots of customers don't report bugs, so the vendor doesn't really know
which bears are out rampaging in the forests.


(e-mailed and posted)


- Bob
--

Return to the comp.compilers page.
Search the comp.compilers archives again.