delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/06/21/02:11:55

Date: Mon, 21 Jun 1999 09:09:24 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Erik Berglund <erik2 DOT berglund AT telia DOT com>
cc: Andris Pavenis <pavenis AT lanet DOT lv>, djgpp-workers AT delorie DOT com
Subject: Re: Fw: Re: Re: gcc-crash - and a possible solution
In-Reply-To: <MAPI.Id.0016.00333138303633303030303930303039@MAPI.to.RFC822>
Message-ID: <Pine.SUN.3.91.990621090817.17143D-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 Sun, 20 Jun 1999, Erik Berglund wrote:

> For instance, gcc could initially allocate a big internal buffer with a
> single
> DPMI-malloc call, say 8 Mbyte, and then just leave the DPMI alone
> until program exit, and instead do some faked malloc2()/free2()
> that only operate towards the internal buffer. The idea is
> keep DPMI out of business as much as possible. gcc would 
> run faster too, I think, if we could avoid excessive DPMI-calls.

IMHO, we need first to understand the problem, and only then try to
devise a solution.  Right now, I would *really* like to know what line
in `free' crashes, and what pointer/variable causes it to crash.
"Page Fault" exception means that GCC tries to access uncommitted
memory, and I would like to understand how the heck does that happen.

> 1) Why does it seem to always work with Unixy sbrk?

I have no idea; this is a part of the puzzle.

> 2) Unixy sbrk uses sbrk16.asm. Why does sbrk16.asm
> have to be copied into DOS memory?

Because it must run as 16-bit code.

> 3) What's so special with gcc, cpp, cc1, as and ld?
> Do they use djgpp and/or sbrk in a special way?

There's nothing special about the compiler as far as memory allocation
is concerned; no special usage of DJGPP or sbrk is present in the
compiler, as far as I know.  Chances are, you simply bumped on some
very rare situation that triggers some subtle bug.

> 4) Are there any uninitalized stack variables?

I don't understand the question.  Stack variables are always
uninitalized, unless the code explicitly initializes them.

> 5) The error seems to depend on a certain program
> sequence previously run, that is, it's depending on
> the current state of the RAM bits (128 Mbyte, that's 1 Gbit).

What's the question?  Anyway, this is typical for memory-related
problems: they usually come and go as function of how memory was used
before the program with the bug runs.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019