Date:	Tue, 28 Jul 1998 10:45:00 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Victor <fesenko AT pacific DOT net DOT sg>
cc:	djgpp AT delorie DOT com
Subject:	Re: Question about debugging
In-Reply-To:	<35b9bec8.1268030@news.pacific.net.sg>
Message-ID:	<Pine.SUN.3.91.980728104439.4133B-100000@is>
MIME-Version:	1.0

On Sat, 25 Jul 1998, Victor wrote:

> I'd appreciate if someone could give me some idea how to debug my
> code.

It's quite hard to do that without more details, especially since I
don't know anything about Allegro.

So I will just point out the noteworthy parts of the traceback.  Hope
that will help you to zero in on the villain(s).

> Exiting due to signal SIGILL
> Invalid Opcode at eip=00aeacac

This EIP is bogus.  AFAIK, a valid EIP cannot be more than EBP,
because the stack is above the code in the DJGPP memory layout.  So
you need to find out how did that EIP happen.

> eax=000a19fb ebx=00aea000 ecx=00000001 edx=00970000 esi=00aeb351 edi=000a1a04
> ebp=007ba2c4 esp=007ba2b2 program=C:\TEMP\PROG.EXE

Note that EBX and ESI are very close to the bogus EIP value.  Maybe
looking at the machine code near the point of crash will give you some
ideas about this.

> cs: sel=00a7  base=10000000  limit=00c0ffff
> ds: sel=00af  base=10000000  limit=00c0ffff

This limit means that the program uses about 12MB of memory.  Does
this make sense?

> It's interesting to note that under slightly different environment
> (for example, I added some code to print the value of some variables
> into a text file) the GPF still occurs and the last address is still
> 0x00aeacac but the previous frame is at line 499 of stretch.c.

This might mean that something is overwriting the stack.

> stretcher_info[i].data  aea000

Note that this is close to the bogus EIP again.

- Raw text -