Sender: "Rolf Campbell" <cp1v45 AT nortelnetworks DOT com>
Message-ID: <37723B04.9E96FDAD@americasm01.nt.com>
Date: Thu, 24 Jun 1999 10:04:52 -0400
From: "Rolf Campbell" <cp1v45 AT nortelnetworks DOT com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
To: djgpp AT delorie DOT com
Subject: Re: My 3d-Engine acts as if on drugs
References: <37710338 DOT 8513182C AT swipnet DOT se> <3771203B DOT 1341C69F AT americasm01 DOT nt DOT com> <3771E1D8 DOT 5BC596F AT eik DOT bme DOT hu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id KAA09191
Reply-To: djgpp AT delorie DOT com

"Dr. András Sólyom" wrote:

> "Campbell, Rolf [SKY:1U32:EXCH]" wrote:
> >     Old code (that worked before) failing now, is a sure sign of wild
> > pointer access.
>
> Most probably. But: Can it be caused by some compiler problems?

    Technically, it could, but I doubt that it is.

> I have a code
> that is working when compiled with DJGPP V2.1 and fails with GPFs when
> compiled with V2.2. It is not very big (about 2000 lines), I tried to find
> pointer errors by a) examining the code very carefully and b) by using malloc
> debuggers under Linux, where I could find no problems.

    This is even more convincing that it is a wild pointer (accessing beyond the
end of allocated blocks).  I've seen this before, and if I remember right, v2.2
uses a different style for memory allocation.  In 2.1, after a header is tacked
on to the malloc block, the size is rounded up to the nearest power of 2.  This
means there is usually a sizable cushion at the end of each malloc'ed block
where technically you can write without getting errors.  In v2.2, it is done
some other way which removes that cushion and thus makes a bug in your code more
obvious.

--
     -Rolf Campbell (39)3-6318