From: fesenko AT pacific DOT net DOT sg (Victor)
Newsgroups: comp.os.msdos.djgpp
Subject: Question about debugging
Date: Sat, 25 Jul 1998 11:29:38 GMT
Organization: Subscriber of Pacific Internet, Singapore
Lines: 72
Message-ID: <35b9bec8.1268030@news.pacific.net.sg>
NNTP-Posting-Host: dyn240ppp118.pacific.net.sg
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

I'd appreciate if someone could give me some idea how to debug my
code.
My problem is that the software I'm writing gets a GPF inside one of
the Allegro's functions - stretch_blit(). I don't think Allegro's at
fault here, but I'd appreciate if you could give me some hints on how
to tackle the problem.
One problem is that this function (stretch_blit()) is using assembly
code for stretching and this complicates matters a lot.
I'm using Allegro 3.0 and gcc ver.2.7.2.1. I tried this on different
machines - with 20Mb of RAM and with 64Mb of RAM and with the same
results. But under Win95 the bug doesn't show up.
The arguments passed to stretch_blit() are valid.

This is the traceback.

Exiting due to signal SIGILL
Invalid Opcode at eip=00aeacac
eax=000a19fb ebx=00aea000 ecx=00000001 edx=00970000 esi=00aeb351
edi=000a1a04
ebp=007ba2c4 esp=007ba2b2 program=C:\TEMP\PROG.EXE
cs: sel=00a7  base=10000000  limit=00c0ffff
ds: sel=00af  base=10000000  limit=00c0ffff
es: sel=00bf  base=00000000  limit=ffffffff
fs: sel=00bf  base=00000000  limit=ffffffff
gs: sel=00bf  base=00000000  limit=ffffffff
ss: sel=00af  base=10000000  limit=00c0ffff
 
Call frame traceback EIPs:
  0x00aeacac   0xaeacac
  0x0004c826   _do_stretch_blit+946, line 522 of stretch.c
  0x0004ccca   _stretch_blit+50, line 602 of stretch.c
  0x0001ba71   _showandask+141, line 456 of grab.c
  0x0001b8dc   _final+220, line 355 of grab.c
  0x0001b0da   _Select+234, line 233 of grab.c
  0x0001ad02   _Grab+586, line 131 of grab.c
  0x00008f78   _Action3+700, line 97 of in.c
  0x000068f1   _main+4085, line 307 of in.c
  0x000627b2   ___crt1_startup+138

This information I've got with the debugging version of liballeg.a,
otherwise it's quite obscure.

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.
So I tried to check the parameters passed to the function
_do_stretch() which is at line 499.
the first 2 arguments are BITMAP* source and BITMAP* dest, so I
checked their sizes:
source->w  852
source->h  906
dest->w    640
dest->h    1638
stretcher_info[i].data  aea000
sx         0
sy         0
syd        4
dest_x     10
dest_y     10
dest_height   250
dest->vtable->color_depth   8

I'm quite at a loss what to do next, and I've checked the stack and it
was about 510K before calling stretch_blit() and I'm not using
recursive functions. (I'm actually allocating 512K to stack).
The only guess could be that some other function destroys some portion
of stretch_blit() routine in RAM.

Thanks for your time.
Victor.
fesenko AT pacific DOT net DOT sg