Date: Mon, 16 Aug 1999 10:07:03 -0500
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: cwsdpmi r5
To: djgpp-workers AT delorie DOT com
Message-id: <37B82917.110C678B@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
X-Mailer: Mozilla 4.05 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990608114406 DOT 4197M-100000 AT is>
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

> On Mon, 7 Jun 1999, Eric Rudd wrote:
>
> > The biggest problem I've had is a propensity for gcc to crash on
> > systems which use HIMEM.SYS but not EMM386 or Windows.  The
> > symptoms, which occur on about 1% of the compilations, are a bomb in
> > an RMCB with a traceback.  The keyboard then invariably locks up,
> > necessitating a hard re-boot, though the disk cache continues to
> > commit normally after the lock-up.
>
> FWIW, I have never seen such problems (but then I never use HIMEM-only
> systems long enough to see a 1%-chance problems).
>
> > I have observed this problem on several computers.  Oddly enough, my
> > own DJGPP-compiled apps have never had this problem.
>
> Are the compiler binaries old by any chance?  If they were built with
> old versions of DJGPP, then this might be due to a problem whereby if
> the compiler crashed, it would leave some exception handlers pointing to
> void, because the abnormal exit code bypassed the function that restored
> the old handlers.

I'm using the gcc 2.8.1 and cwsdpmi r4 binaries in the released
gcc281b.zip and csdpmi4b.zip.

> > I don't know what I can do to diagnose the problem, other than to
> > manually transcribe the traceback.
>
> Please post at least one case of this with the traceback and any other
> relevant information.

Since this problem locks up the keyboard, there's no easy way to get the
traceback.  The problem finally bugged me enough over the weekend that I
manually transcribed the traceback off the screen and typed it in after
re-booting.  Here it is:

Page Fault cr2=06000001 in RMCB at eip=e5c3; flags=3046
eax=06000001 ebx=000010b6 ecx=00000000 edx=00017daa esi=00001a65
edi=000020bc
ebp=00064e24 esp=000020a0 cs=a7 ds=3b es=33 fs=33 gs=bf ss=33 error=0006
Exiting due to signal SIGSEGV
General Protection Fault at eip=0000e614, error=10d4
eax=dededede ebx=000010b6 ecx=00000000 edx=00017daa esi=00001a65
edi=000020bc
ebp=00064e24 esp=000020a0  program=C:\DJ202\BIN\GCC.EXE
cs: sel=00a7  base=10000000 limit=0006ffff
ds: sel=003b  invalid
es: sel=0033  invalid
fs: sel=0033  invalid
gs: sel=00bf  base=00000000 limit=0010ffff
ss: sel=0033  invalid
App stack: [00656d0..000256d0] Excptn stack: [000256b0..00023670]
Call frame traceback EIPs:
  0x0000e614
  0x000176ff
  0x0001806c
  0x00018cd8
  0x000112cf
  0x0000ca8b
  0x0000695e
  0x00008ce0
  0x0000a36b
  0x00009d00
  0x0000a36b
  0x00009d00
  0x0000a36b
  0x00009d00
  0x0000a36b
  0x00009d00
  0x00008a8e
  0x000065c6
  0x0000e316

Just before this particular crash, I typed ahead the name of the binary
that gcc was busy compiling when it crashed, so that I could run it.  The
first four characters of the name appeared on the command line at the time
of the crash, so there's some weird delay going on here (I have DOSKEY
installed).

Since I'm running straight DOS at home, I don't have LFN support, so I
can't rebuild the binaries with debug info -- this un-annotated traceback
is the best I can do.  I'm running the Norton cache at home, which *might*
be involved, but I've also had this problem at work, running DOS 7 and
SMARTDRV in MS-DOS mode.  I have never observed this problem while running
in a DOS box, however.

-Eric Rudd