To:	dj AT ctron DOT com
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: GCC crashes in XMS mode
Date:	Mon, 30 Jan 95 15:06:38 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>

I wrote:

> A number of users reported recently that gcc 2.6.3 with 1.12m3
> hangs when not running in VCPI or DPMI mode.  Testing on my
> system reveals that this happens both in raw extended memory
> (plain vanilla DOS system) and XMS (plain vanilla system with

Here is some more info:

  * GCC.EXE crashes at address 0xC207.  The following code fragment
    is found at that location (displayed by FSDB 0.91a):

      push  ebx
      push  edi
      mov   edi,edx
      mov   ax,768
      mov   bx,33
      mov   cx,0
      int   49

    This is apparently a fragment from access.c which calls DPMI
    function 03 (AX = 0300h = 768) to invoke INT 21h (BX = 21h = 33).
    By looking at the regs structure I was able to confirm that Int
    21h is called with AX = 4300h (get file attribute bits).

  * The call stack at this point is:

      c207
      4286
      94fe
      118e

  * At this particular location the program calls access() with the
    name of the temporary subdirectory of the main DJGPP directory,
    like this: 

        access("c:/djgpp/tmp".....)

This isn't a simple access() bug, because a short program which just
calls access with the string it gets from the command line works OK in
both XMS and raw extended memory modes.  (Of course, it can be that I
failed to correctly simulate the call environment, but that would also
mean that the bug isn't ``simple''.)  Another possibility would be
that the bug is inside go32, where it simulates DPMI calls, but again
it doesn't pop up on any call to access().

Without GCC source I couldn't advance further, and I wasn't on the
warpath enough to download the entire GCC source distribution.  Hope
somebody out there who already has the source will track this bug.

- Raw text -