Date:	Tue, 2 Jan 2001 10:52:48 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Paul Forgrave <forgrave AT cyberus DOT ca>
cc:	djgpp AT delorie DOT com
Subject:	Re: RHIDE 1.478 Unstable?
In-Reply-To:	<000b01c07430$c73056a0$9d42c3d1@software.mitel.com>
Message-ID:	<Pine.SUN.3.91.1010102102749.18307A-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -