From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108131443.AA13991@clio.rice.edu>
Subject: Re: Selector Exhaustion
To: acottrel AT ihug DOT com DOT au (Andrew Cottrell)
Date: Mon, 13 Aug 2001 09:43:40 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com, pavenis AT lanet DOT lv
In-Reply-To: <026201c12403$e0d609f0$0a02a8c0@acceleron> from "Andrew Cottrell" at Aug 14, 2001 12:26:00 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> The original code leaked DPMI selector like a sive on Win2K when building
> LIBC on Win 2K, it was a night mare to have to restart every minute or two.

When I get around to trying to create merged code I'll document some of
the reasons why, but for now just know that large builds are completely
unusable on Windows 2000 without doing something about selector exhaustion.
(One reason I see is that Windows 2000 does not allow 8192 selectors for
DPMI usage in the LDT - much less).  Also using unixy sbrk() eats up more
selectors - which is also a reason I thought we had to fix non-move for NT/2K.

> > > General Protection Fault at eip=000013f5
> > > eax=00330901 ebx=00000033 ecx=00330000 edx=001a8338 esi=00000187
> > > ebp=6269091e esp=00000740 program=D:\dj204\BIN\gcc.exe

> > Looks like the stack is smashed (EBP actually looks like ASCII text).
> > Did you try to stubedit gcc.exe to a larger stack?
> I need to read and try to understand the FAQ section 12.2. Is there any
> further pointers on what to look for in the registers or should I just keep
> on sending the crash info?

The printout showed an app stack, so it was allocated OK.  ESP is in
the null page (oops).  EBP is text.  Stack smashage.

> > Also, the EIP value seems right at the program start.  Can you see
> > where it is, exactly?
> I need to do some background reading in the FAQ and GDB etc on this so I can
> give the info next time the crash occurs or is it too late once the crash
> occurs?

Using gdb or edebug to locate the EIP location might help, but with stack
smashage we may have just jumped randomly.  If it's reproducible try to
increase stack size.  If not, there is some call that failed that we didn't
catch (or an uninitialized variable).