Mail Archives: djgpp-workers/1999/08/16/12:12:57
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
- Raw text -