Mail Archives: djgpp/1998/07/25/07:45:23
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
|
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
- Raw text -