Mail Archives: djgpp/1998/10/24/18:16:59
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 <assert.h>,
> and then:
>
- Raw text -