Date: Mon, 22 Sep 1997 19:41:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@bitbox.follo.net (Eivind Eklund) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: Bug in malloc/free (was: Memory leak in getservbyXXX?) Message-ID: <199709221941.MAA18135@usr06.primenet.com> In-Reply-To: <19970922113306.60050@bitbox.follo.net> from "Eivind Eklund" at Sep 22, 97 11:33:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Why make it this hard, and subject to trashing of the list count? The
> > > following code will check for a circular loop (no knowledge of length
> > > required) for a single-linked list:
> >
> > Because we want to locate the erroneous entries, and the entries most
> > likely to have been trashed to create the loop in the first place, in
> > order to report them (and hopefully get the probem corrected).
> >
> > This whole thread has really been about finding problems in code using
> > the memory allocation code.
>
> So? I can't see that you need to count to do this. The list itself
> is enough, even though the counter in itself might be information you
> would like to have. You just don't need it for actually finding the
> loop, the loop length or where the loop start; you cut the part which
> actually described this, the code was just a better way of
> implementing the list verificiation itself, and not to be taken
> verbatim. abort() was just to make it obvious where you saw that the
> list had looped.
Seeing that the list has looped does not guarantee that you know
where the last valid entry, or first invalid entry, exists.
I don't even agree that your method actually finds the list loop, unless
you somhow guarantee that the loop goes back to the had such that your
pointer comparison is valid.
If I have a loop:
,-------------------------.
head v | orphan tail (may not exist)
>---------------------------------------------'----------->
(3) (1)(2)
The problem is that I don't know where the corruption occurred. I
don't know if there is an orphan tail (as shown) because the corruption
occurred at the point where it upturned (1), or if there is *no* tail, and
the corruption occurred because the previous to last entry overwrote
the last entries NULL pointer (2), or if there was corruption of the next
pointer early in the list (3), causing it to point to a record later
in the list than it should.
I would like to identify all 4 of these user addresses (which are not
equal to the malloc() structure addressses, but instead the user data
offset following them, so that I can definitively say "one of these
addresses which malloc() returned to you is being overrun by you, and
this is resulting in a pointer corruption".
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709221941.MAA18135>