From: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: GPF decoding
Date: 28 Aug 1997 08:52:04 GMT
Organization: The National Capital FreeNet
Lines: 48
Message-ID: <5u3e7k$con@freenet-news.carleton.ca>
References: <3403DAF8 DOT 7841 AT post DOT comstar DOT ru>
Reply-To: ao950 AT FreeNet DOT Carleton DOT CA (Paul Derbyshire)
NNTP-Posting-Host: freenet6.carleton.ca
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk


> Shutting down Allegro
> Exiting due to signal SIGSEGV
> General Protection Fault at eip=1cf8b; flags=3016
> eax=00030000 ebx=0000000d ecx=ffffffff edx=30202020 esi=30202020
> edi=30202020
> ebp=0000000d esp=00033260 cs=a7 ds=af es=af fs=b7 gs=bf ss=af error=0000

In human terms:

eax, esp are near each other. Likely pointers. Maybe bad
pointers...outside an array perhaps?
ebx is the number 13, ecx is probably an int equal to minus one. Where
might your program use, or generate the ints 13 and -1 near each other?
The 13 may also be a newline in text or string processing. The ffffffff
might also be an EOF or error indicator in file I/O. Do you check for
error after I/O function calls? If not, and one happens, this can cause
your program to crash.
edx, esi, and edi: 30202020 looks like perhaps a piece of a string: "0  
", zero and four spaces. Where might that crop up? Check for string
constants, printfs with numerical input and lots of spaces, and file I/O
with files containing those four characters.

Assuming esp is the stack pointer, a function was entered and its args and
automatic variables go up to 0x33260. eax was 0x30000, probably a pointer
to an automatic variable in it or an earlier function. Perhaps it's an
out-of-bounds pointer.

The lack of call frame is itself significant. It may have died in an
exception handler. Did you write your own? Allegro's exception handler was
evidently called by looking at the first line. Did you use Allegro
correctly? You did lock all memory touched by timer interrupt routines and
vsync interrupt routines right? You did lock the routines themselves right?
Did you write some other interrupt handler? That can be tricky. Make sure
you did it right. If you wrote an interrupt handler at all, that's
probably where it crashed. Check for that QDPMI bug. Disable QDPMI and see
if it happens when you run it without (which will invoke CWSDPMI) or from
Windows (assuming you have it), which provides its own DPMI host.
It may also be that your stack was trashed. Writing out of bounds of an
automatic array, then returning from a function can do that. Also,
screwing up inline asm. Did you use any inline asm? Asm is powerful, but
there is the potential to trash things by directly goofing with the stack,
by pushing or popping in an unmatched way for instance.
--
    .*.  Where feelings are concerned, answers are rarely simple [GeneDeWeese]
 -()  <  When I go to the theater, I always go straight to the "bag and mix"
    `*'  bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh