Mail Archives: djgpp/1998/08/10/02:55:05
On Mon, 10 Aug 1998, Jens Hassler wrote:
> Then I looked up the 'set_clip' in the 'init_dialog'-procedure (sourcefile
> gui.c), threw the "set_clip(screen,0,0,SCREEN_W-1,SCREEN_H-1)" line out
> and recompiled Allegro.
>
> And now the problem is even bigger (maybe ;). Now I get error 0004 with
> the following Symify-output:
>
> _button_proc+35, line 205 of padd.c
> _init_dialog+237
>
> padd.c is my sourcefile. Line 205 is "d->dp = layout[k].dat;" (d->dp is a
> void pointer of the dialog routine [points to a bitmap for a d_icon_proc-
> Button-Procedure]).
>
> I don't know what's wrong with the code, so I hope that anybody here is
> able to help me getting this thing work under pure DOS ;-)
No offence, but this all looks suspiciously like stabbing in the dark.
You need a methodical approach here. What you need to determine first
is *exactly* why does the program crash. Only *then* should you
decide how to remedy the problem. Randomly removing lines will not
get you anywhere.
From the fact that you get error=0006/0004, I guess that your problem
is that you are trying to dereference a NULL pointer. This will
usually pass undetected under Windows because the Windows DPMI server
doesn't catch such bugs, while CWSDPMI does. You need to establish
where is that garbled pointer, and then to correct that.
In many simple cases, just debugging near the point of the crash will
reveal which variable is a NULL pointer. If that doesn't help, read
on.
To begin with, reinstate the line you removed. Then run the program
and get it crashed again. Let's assume it crashes again at the same
place (_set_clip+141) as you reported. Now look at the machine
instruction that crashed with a debugger. For example, the GDB
command "disassemble set_clip+141" (note: no underscore in `set_clip')
will display the assembly code for the entire `set_clip' function.
The instruction at _set_clip+141 is the one you are after.
Every instruction can only crash if some of its operands are garbage.
When you have the instruction that crashed, you should have no
problems in identifying the operand(s) which could potentially crash
the program. (If you can't figure it out, post the instruction here
and ask.) Then look at the registers' dump printed when the program
crashes, and find the register with the bad (zero) pointer. After
that, you need to find out which of your variables gets loaded into
that register; use the source and the assembly for that.
Finally, when you know which variable is a NULL pointer, you will have
to understand how did it come into existence, and then correct the
bug.
You can find some more info on related matters in the thread "fsdb
crashes post emacs" where I posted a detailed analysis of a crash
using the method outlined above.
- Raw text -