Mail Archives: djgpp/1998/08/04/16:14:28
On 4 Aug 98 at 12:51, Cephaler wrote:
> Eeek I need help in a big way on this. It seems my less-than-standard asm
> code and I have screwed up something with djgpp. A program yesterday and
> ran fine yesterday won't run today, after I ran a couple odd looking asm
> programs. No extra tsr's...no viruses, no weird stuff going on... I don't
> know what to make of this:
>
> Shutting down Allegro
> Exiting due to signal SIGILL <------------ Hmmmmmmmm
> Invalid Opcode at eip=00092b08
> eax=00000000 ebx=000900af ecx=000000a0 edx=00000000 esi=00000020
> edi=000190a0
> ebp=0008d898 esp=0008d886 program=C:\NICK\DJGPP\GAME\TEST.EXE
> cs: sel=00a7 base=82739000 limit=0019ffff
> ds: sel=00af base=82739000 limit=0019ffff
> es: sel=00cf invalid
> fs: sel=00bf base=00000000 limit=ffffffff
> gs: sel=00bf base=00000000 limit=ffffffff
> ss: sel=00af base=82739000 limit=0019ffff
>
> Call frame traceback EIPs:
> 0x00092b08
>
> I've never gotten that before...did I screw something up in my bios? Even
> after restarting the problem is still there. Help would be greatly
> appreciated
SIGILL means an unsupported exception occured I think. Does this
happen for all djgpp programs? All Allegro programs?
It looks like you have overwritten part of your stack; the EBP and
ESP values are similar enough to indicate that they themselves
probably are correct, but the call frame traceback got nowhere.
My first step would be to get a more useful call frame traceback.
Try running the program from a debugger; this may not work because
you're using Allegro. FSDB and EDEBUG32 both disable some things
Allegro needs to use; I'm not sure about GDB. If this does work,
search from the top of the stack for the two consecutive numbers
"0x00000000" and "0x00001279" (assuming you're using djgpp v2.01).
This is the top of the call stack. Next, keep searching down the
stack for something pointing to this address (of the "0x00000000").
When you find it, the following four bytes point to the next entry in
the traceback (traceforwards?) -- this should be __crt1_startup +
822. Keep doing this, searching down the stack, until you get stuck;
this is the point where your stack has become corrupted.
The latest version of my post mortem debugger can do this for you.
To use this you need to install my core dump system too, which
catches selected signals and writes a file called `core' to disk
containing information about the program when it crashed, including a
memory dump.
I've also written a signal handler that generates these reversed
tracebacks. If you're interested, I can send it.
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
- Raw text -