Date:	Wed, 3 Nov 1999 09:58:56 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Antti =?iso-8859-1?Q?Koskip=E4=E4?= <antti DOT koskipaa AT nic DOT fi>
cc:	djgpp AT Delorie DOT com
Subject:	Re: #PF, #PF, #PF... Aargh, HELP!!!
In-Reply-To:	<381F5DB6.24AE721D@nic.fi>
Message-ID:	<Pine.SUN.3.91.991103095838.29562L-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 2 Nov 1999, Antti =?iso-8859-1?Q?Koskip=E4=E4?= wrote:

> init ();
> playmidi (23);
> init_graphics ();
[snip]
> All is fine until it hits the address 0x163e. Page Fault.
> 
> I first run symify to check where it crashes. Ok. playmidi(23). I always
> check with fsdb what kind of instruction in at the address. It was a CALL.
> Then I comment out the call (in the C code) and try again. Now it
> crashes when it calls init_graphics. Again re-check. Again the CALL
> instruction, and at the same address 0x163e.

First, please *always* post the SYMIFY'ed crash message when you
report such problems.  The crash message includes vital info that
makes it much easier to help you efficiently.  The DJGPP FAQ list
tells in section 12.2 how to interpret the crash message; you might
consider looking that up.

Since you didn't post the crash message, what's below is based on
guesswork, and may be totally off-course.

The symptoms you are describing are typical for programs that
overwrite the stack frame.  A stack frame is a portion of the stack
where arguments to a function are pushed together with the return
address for that function.  If the function overwrites the stack
frame, it can overwrite the saved EBP register with some random
garbage.  When the offending function returns, it pops the garbled
EBP, and the first instruction that uses the stack crashes because EBP
is invalid.

This explains why your crashes keep moving: the offending code that
trashes the stack is *before* the fragments you comment out, so the
same crash happens in the next place that uses the stack.

If my guess is right, you should see an invalid value in the EBP
register printed in the crash message (see why it is important to post
it?).

The real bug in these cases is in some function called somewhere
*before* the crashed CALL.  Examine the code of these functions and
see if any of them passes arguments incorrectly or assigns values to
an automatic (local) array beyond the array's limits.

> This program worked a long time ago... The only thing that is changed
> is my binutils... it's 2.9.1.

How did you compile Binutils 2.9.1? Did you change anything in the
original sources of Binutils?  If you did, it might be that you
introduced a bug there.

> I have used djgpp for years now, and I've never seen such things happen.

It's a bug.  Bugs happen all the time.  Keep looking, you will solve
it eventually.

- Raw text -