Date:	Wed, 18 Aug 1999 16:06:13 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Eric Rudd <rudd AT cyberoptics DOT com>
cc:	djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject:	Re: cwsdpmi r5
In-Reply-To:	<37B82917.110C678B@cyberoptics.com>
Message-ID:	<Pine.SUN.3.91.990818160128.10490X-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 16 Aug 1999, Eric Rudd wrote:

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

Then the compiler binaries are not the problem, at least not in the way I 
thought they might.

How exactly was the compilation run?  Did you invoke gcc from the command 
line? from inside Make? from another DJGPP program?

And how large is the stack in cc1.exe and cc1plus.exe (was it a C++ 
program or a C program, btw)?

Charles, can you see anything in this traceback?  It seems to crash in 
CWSDPMI, but why?

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