Mail Archives: djgpp/2001/01/02/08:00:44
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
- Raw text -