Date: Mon, 10 Aug 1998 09:54:38 +0300 (IDT) From: Eli Zaretskii To: Jens Hassler cc: djgpp AT delorie DOT com Subject: Re: Allegro -> SIGSEGV error In-Reply-To: <6zbSgq51qNB@lukey.crazy.inka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.