From: pavenis AT lanet DOT lv
To: djgpp AT delorie DOT com
Date: Tue, 2 Jan 2001 14:55:27 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: RHIDE 1.478 Unstable?
Message-ID: <3A51EBDF.8051.3AFA99@localhost>
References: <000b01c07430$c73056a0$9d42c3d1 AT software DOT mitel DOT com>
In-reply-to: <Pine.SUN.3.91.1010102102749.18307A-100000@is>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp AT delorie DOT com

On 2 Jan 2001, at 10:52, Eli Zaretskii wrote:

> 
> 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?  

RHIDE only installs handler for SIGFPE when in debugging session
(see dbgcom.c in djlsrXXX.zip). So at compilation time it cannot 
happen. RHIDE always installs handler for SIGINT but it should not 
cause any harm unless Ctrl-C or Ctrl-Break is pressed.

RHIDE overrides abort() to perform some additional operations.
(It is relic from old times, I haven't changed it).
It looks that RHIDE is getting additional exception after 
raise(SIGABRT) in abort(). It's difficult to say what happened but 
perhaps easiest would be to try running RHIDE under debugger (if it's 
possible under WinNT at all). Perhaps it would be possible to set 
breakpoint to abort() in idemain.cc and see why (and where) it was 
called from.

I put RHIDE executable compressed with ZIP at
	http://www.lanet.lv/~pavenis/rhide/idegc.zip


Andris