Mail Archives: djgpp/1998/04/20/09:11:32
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> On Fri, 17 Apr 1998, Salvador Eduardo Tropea (SET) wrote:
>
> > The FACT is that gcc is sensitive to PHYSICAL memory, don't ask
> > me way or how, I really don't understand the effect. For some tasks
> > gcc really needs PHYSICAL memory and all the virtual memory in the
> > world doesn't help a bit.
>
> I find this hard to believe. Neither the compiler nor the library can
> distinguish between physical and virtual memory, except at levels
> below `malloc'. Could you please post a program that caused the
> compiler to behave this way?
I can't post such a thing, isn't easy to reproduce. I even thinked that was
something relating to my system, but I saw this problem in the machines of
other users. The problem is normally triggered by C++ programs using huge
ammounts of headers. If you have enough physical memory the problem NEVER
appears.
> > A good example in my system is that W95 some times eats enogh
> > physical memory to make fail my compiling, under plain DOS the same
> > is when RHIDE uses 2Mb more than normally (for example: too much
> > editor opened and InfView with a huge info file, or debug info
> > loaded in memory).
>
> I routinely leave Emacs to run for several days on end, doing
> everything from within it, including compilations. This usually
> causes it to stabilize at 20MB after a couple of days (I have several
> huge files loaded into it permanently). But I have never seen a case
> of compilation which failed from Emacs but worked from the DOS
> prompt. All I see is some disk activity due to swapping.
How much physical memory do you have in this machine? Do you compile heavy C++
code?
> > I don't understand why it happends because gcc uses malloc (or I'm
> > wrong in it, could it use sbrk() for something?).
>
> As far as I could see, gcc 2.7.2.1 only uses `sbrk' to report memory
> usage. So this shouldn't be the reason.
But the fragmentation of the memory could be the reason.
I saw these kind of problems from the beginning. When I started to use djgpp, I
was using a different computer with a different amount of RAM, with a different
gcc and with a different djgpp version. But the problem was there too. I
remmember that the first time I compiled RHIDE I got some "internal error"
from the C++ compiler, the only way to workaround it was running the makefile
from a Win3.1 DOS BOX!!! that looks VERY silly because there are less memory in
this case. The problem just dissapears if you have more physical memory.
Perhaps is all related to bugs in GCC 2.7.x/8.x that are sensitive to the
memory layout. But the problems exists, for some strange reason gcc is
sensitive to the physical free memory. I can't explain why, I can't give you an
example because this will fail in some system and work in other. Most of the
time the error is an "internal error" some times the compiler dies with a GPF.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -