Message-ID: <36328A07.BDD52205@stargate.net> Date: Sat, 24 Oct 1998 19:16:39 -0700 From: John Kissell X-Mailer: Mozilla 4.02 [en] (Win16; I) MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp To: djgpp AT delorie DOT com Subject: Re: Nested structure problem (maybe)? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com 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: 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*. Again, thanks for your help. George Foot wrote: > > On Sat, 24 Oct 1998, John Kissell wrote: > > > The following is a snippet from a 'C' file that contains many long and > > nested structures. By nested, a main structure 'OBJECT_TYPE *list' > > contains pointers to other structures which contain pointers to lesser > > structures and so on. It compiles and links with no errors *or warnings* > > but I get a SIGSEGV at the 'p=record->text;' line. The rub is that Rhide > > in 'run to cursor' and then debug shows that record->text contains a > > valid string of type char, and in fact, the correct string in the > > correct place for the file that was read in as a test of the code! But > > the program when run unhindered under Rhide stops with a SIGSEGV at the > > 'p = record->text;' line? > > When programs are run under a debugger their environment is > different, so they can behave differently (if the code is > wrong, of course -- correct code should work the same way in > both cases). > > Try dumping to a disk file, or stderr, the value of `record' > before the above assignment. They you may be able to spot > whether or not it's a valid pointer (but you'll need to take a > look at more of the crash dump to do this). > > Also note that in optimised programs it's sometimes not possible > to determine exactly which line was being executed at the time > of the error. That's not advocating that you shouldn't use > optimisation; just that you should be aware of this fact when > you debug your code. > > > ps. I typed part of the error codes generated when the program was run > > directly from the DOS prompt (from a 'print screen' printout). I would > > like to capture them all to include here but I dont know how. :( > > Use `redir': > > redir -e crash.txt myprog.exe > > That will capture everything sent to stderr (including the crash > dump) and redirect it to the file `crash.txt'. I believe > `symify' can also do this, after the event, if you type: > > symify -o crash.txt myprog.exe > > I also suggest you put in some assertions. Before dereferencing > any pointer, assert that it is not NULL. #include , > and then: >