Date: Tue, 2 Jan 2001 10:52:48 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Paul Forgrave cc: djgpp AT delorie DOT com Subject: Re: RHIDE 1.478 Unstable? In-Reply-To: <000b01c07430$c73056a0$9d42c3d1@software.mitel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 1 Jan 2001, Paul Forgrave wrote: > To comply with the request for more info, see the following: Thanks for a comprehensive and accurate report. Hopefully, Andris will be able to correlate the stack dump with the sources and find what is crashing. > Exiting due to signal SIGSEGV > General Protection Fault at eip=001e8d60 > eax=fee50000 ebx=fee50000 ecx=00000302 edx=fee60000 esi=00000090 > edi=fee500a0 > ebp=002d33d4 esp=002d339c program=H:\DJGPP\BIN\RHIDE.EXE > cs: sel=01c7 base=03020000 limit=7cfcffff > ds: sel=01cf base=03020000 limit=7cfcffff > es: sel=01cf base=03020000 limit=7cfcffff > fs: sel=0000 > gs: sel=01d7 base=00000000 limit=0010ffff This FS=0000 thing repeats itself in all the crashes you posted. A zero selector is an invalid selector. The DJGPP program's entry point is entered with FS loaded with the program's data segment selector, and I don't think it ever changes unless the program uses FS, e.g. for _farpeekb and similar functions. If a program does use _farptr functions, FS should usually be loaded with a selector which has the same base address and limit as in GS above. So who loads FS with zero, and does that have anything to do with the crashes you describe? I don't know, but you could try disassemblying rhide.exe at 0x001e8d60, the address where it crashed, and seeing if the instruction at that EIP references FS in any way. GDB or RHIDE's built-in debugger is one way of producing the disassembly; the `objdump' utility, which is part of Binutils, another. > RHIDE internal error. Please send a description of this situation > as most as possible detailed to the author together with the version > you are using. AND VERY IMPORTANT IS THE NEXT TRACEBACK!!!! > > Exiting due to signal SIGABRT > Division by Zero at eip=0001d48d, x87 status=0000 > eax=000000c8 ebx=00302f48 ecx=00000000 edx=0001df0a esi=00313658 > edi=00302f48 > ebp=002d3324 esp=002d32fc program=H:\DJGPP\BIN\RHIDE.EXE > cs: sel=01cf base=032c0000 limit=0031ffff > ds: sel=01d7 base=032c0000 limit=0031ffff > es: sel=01d7 base=032c0000 limit=0031ffff > fs: sel=01df base=00000000 limit=0010ffff > gs: sel=01df base=00000000 limit=0010ffff Note how in this traceback, which is not a real crash, just a result of a call to abort() inside a SIGFPE signal handler, the FS selector is identical to the GS selector--this is the normal situation in DJGPP programs. Andris, is this version of RHIDE the first one to install a signal handler for SIGFPE, or did previous versions (like 1.4.7) do that as well? NT doesn't like DJGPP programs which catch SIGFPE: a program that does that, has a high probability of crashing when it actually catches a signal. For that matter, any other signal that uses the invalidate-DS technique will, when caught, make the program unstable on NT. The FAQ has more details in section 3.3.