Date: Mon, 21 Jun 1999 09:09:24 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Erik Berglund cc: Andris Pavenis , djgpp-workers AT delorie DOT com Subject: Re: Fw: Re: Re: gcc-crash - and a possible solution In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.