Sender: nate AT cartsys DOT com Message-ID: <363378A2.6F4A4E55@cartsys.com> Date: Sun, 25 Oct 1998 11:14:42 -0800 From: Nate Eldredge X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i486) MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: Nested structure problem (maybe)? References: <36328A07 DOT BDD52205 AT stargate DOT net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com John Kissell wrote: > > Thank you, I had read about symify and redir at this news group but > could'nt remember the command names or how to use them. I'll try out > 'assert' as soon as I get a chance. A full crash dump from symify > ('symify' appears to yield more information than 'redir' in this case ) > follows: `redir' doesn't give any information, it just saves the dump in a file. It has other uses, too; read its docs. > Shutting down Allegro > Exiting due to signal SIGSEGV > Page fault at eip=000046b4, error=0004 > eax=00000000 ebx=00006bc4 ecx=0000000a edx=0008f0a0 esi=00000054 > edi=0004c790 > ebp=0008c2dc esp=0008c04c program=C:\DJGPP\BP2\G53.EXE > cs: sel=00a7 base=10000000 limit=003dffff > ds: sel=00af base=10000000 limit=003dffff > es: sel=00af base=10000000 limit=003dffff > fs: sel=00bf base=00000000 limit=ffffffff > gs: sel=00bf base=00000000 limit=ffffffff > ss: sel=00af base=10000000 limit=003dffff > > Call frame traceback EIPs: > 0x000046b4 _ParseFile+536, line 532 of g53.c > 0x00006f6e _Filer+938, line 1170 of g53.c > 0x00002404 _MouseTrap+92, line 456 of g53.c > 0x00007d4f _main+319, line 1237 of g53.c > 0x000321a6 ___crt1_startup+138 > > C:\DJGPP\BP2>symify -o tmp.txt g53.exe > > The call frame trace backs are pretty straight forward but how can I > make use of the rest of the information, error=0004 for example? I was > digging around in the info program and most of the topics I tried to > read dont exist on my computer, guess I'll need to download a full dose > of *info*. Actually, I don't think all of the dump is documented. But most of what you see is the contents of the CPU registers at the time of the crash. The segment registers show you their base and limits, so you can possibly guess whether some of your pointers were legal (anything above the limit isn't). The error code is a bit trickier, it's created by the processor when the exception occurs. If the error is a page fault, the lowest three bits give you this information: bit 0 (least significant bit): 0 = Caused by not-present page (completely inaccessible, like the NULL page) 1 = Caused by protection violation (like trying to write read-only page) bit 1: 0 = Caused by a read 1 = Caused by a write bit 2: 0 = Happened in supervisor mode 1 = Happened in user mode (the normal case) So in your case, the fault was caused in user mode by trying to read a non-present page. If the error is a General Protection Fault (the other common case), it usually means you flew right past the segment limit with a pointer, though there are other cases. If the error code is nonzero, it means some bogus value was loaded into a segment register, and it has that value. You can get more info by disassembling your the function that crashed and looking at the instruction at the "eip" address; it caused the fault. You can figure out which register held the bad address, find out from the dump what its value was, and try to deduce how it got there. Debugging is an art, not a science. -- Nate Eldredge nate AT cartsys DOT com