Mail Archives: djgpp-workers/1999/06/21/02:11:55
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 -