Xref:	news2.mv.net comp.os.msdos.djgpp:989
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Guide to understanding error dumps? (was NOT grx 2.0 problem, stack problem)
Date:	Sun, 11 Feb 1996 18:52:30 CST
Organization:	Rice University, Houston, Texas
Lines:	35
Message-ID:	<311e8f4e.sandmann@clio.rice.edu>
References:	<01I11VYKXNTY000106 AT VAX1 DOT ROCKHURST DOT EDU> <311e3cbf DOT sandmann AT clio DOT rice DOT edu> <311E50E3 DOT 18F366F7 AT alcyone DOT com>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> I've seen enough of these kinds of questions that it occurs to me that it
> might be valuable for someone to put together a guide to understand the error
> dumps that DJGPP spits out when it crashes; if understood properly, they would
> tend to help narrow the problem area down a great deal.  Unfortunately, most
> people just aren't used to the error dumps that DJGPP puts out.

It is very true that the error dumps are cryptic.  They contain nothing more 
than the machine state at the point of error.  The problem in diagnosing 
them is one of understanding the Intel architecture, which means obtaining,
reading, and understanding the Intel i386/i486/Pentium Microprocessor
programmers' reference manual.  You must also understand a bit about what
the registers are used for and what normal values might be expected in them;
unless you know at least a little about Intel assembler, this won't happen.

The most useful information for the casual user is the text message of 
what happened with the EIP value, which tells where it happened.  Using
symify (especially when compiling with -g), you can get a very accurate 
description of where the error happened.  When you look at the assembler
listing in a debugger of that line, with the register values displayed, you
can go a long way towards reconstructing what was happening at the time of
the failure.

Honestly, most people don't have the desire to obtain that level of skill
in debugging, so I'm not sure a guide to understanding error dumps would
do that much good.  It's hard enough just getting people to write them down
if they have a problem - and we almost never get one which is symified.

If I were to write some rules:
1) Compile with -g
2) symify all errors
3) EBP and ESP should be relatively close (when not using -fomit-frame-pointer)
4) EBP and ESP should be about image size + stack size (256K) in hex
5) The 4 least significant bits in CS,DS,ES,FS,GS,SS should be 7 or f on
   almost all dpmi providers (or you may be faulting inside the DPMI itself)
6) Try to look at a few of the dumps instead of ignoring them all :-)

- Raw text -