Very Computer

  I've found a possible cause of my linux woes.  Here's the scenario:
# top
( top reports 11 M of RAM used, 30+ avail )
# gcc -o example -I/home/threads example.c -L/home/threads -lcthread
[successful compile]
# top
( top reports 11.5 M RAM used, 29.5 avail )

I've can repeat this indefinitely until I'm out of ram completely.
Moreover, all of the ram is going into the "Buff" (buffers) item
from top.  None of this memory seems to be relinquished by gcc
or otherwise on termination of gcc or shell.

(When you sort on mem usage from top, it says that the various
 login processes are only using ~ 1.5% of available mem, which
 doesn't nearly account for the 10+ megs of ram that Linux says
 I'm using..)

I'm using Linux 2.0.18 (RH 4.0) and gcc 2.7.2 ...

Has anyone had similar problems, and is there a workaround?

--

           'O, there has been much throwing about of brains.' -ws

Quote:>   I've found a possible cause of my linux woes.  Here's the scenario:
> # top
> ( top reports 11 M of RAM used, 30+ avail )
> # gcc -o example -I/home/threads example.c -L/home/threads -lcthread
> [successful compile]
> # top
> ( top reports 11.5 M RAM used, 29.5 avail )

> I've can repeat this indefinitely until I'm out of ram completely.

Quote:> Moreover, all of the ram is going into the "Buff" (buffers) item
> from top.  None of this memory seems to be relinquished by gcc
> or otherwise on termination of gcc or shell.

IOW, this sounds like normal behavior for Linux...or NT or Solaris
or...lots of virtual-memory OS's with decent disk caching.

---

 Wasatch Communications Group               http://www.wasatch.com

  Question 6.2.  Free memory as reported by free keeps shrinking.

  The `free' figure printed by free doesn't include memory used as a disk
  buffer cache - shown in the `buffers' column.  If you want to know how
  much memory is really free add the `buffers' amount to `free' - newer
  versions of free print an extra line with this info.

  The disk buffer cache tends to grow soon after starting Linux up, as you
  load more programs and use more files and the contents get cached.  It
  will stabilise after a while.

--

 .  _\\__[oo       from       | Phones: +44 121 471 3789 (home)

.  l___\\    /~~) /~~[  /   [ | PGP-fp: D7 03 2A 4B D8 3A 05 37...
 # ll  l\\  ~~~~ ~   ~ ~    ~ | http://wcl-l.bham.ac.uk/~bam/

: When you say "out of RAM" do you mean your machine is dead in
: the water and you can't launch any more programs?  Or do you mean
: it's all allocated to the buffer cache, which is not the same
: thing as being "out of memory" at all.

   Both :) After having messed around with a bit more, I can
see that you are right; it's just* onto some stuff as
cache or whatever while I'm not doing anything else.

   OTOH, my Linux likes to do some weird stuff after I've been
running for an hour or so.  For instance, I'll be in X, and I'll
load a couple xterms and a Netscape window open, and pretty soon
windows just start disappearing off the desktop; occasionally the
whole thing crashes and I wind up back at a textmode prompt.  
Attempts to run any kind of diagnostic tool at that point (such as
ps) usually put me in that must-hit-reset cpu state.  [And then fix
my hard drive... :) ]  Or once in awhile everything from vi to ld
will start core dumping..

--

           'O, there has been much throwing about of brains.' -ws

: Or, to put it another way, have you considered the possibility of
: reading the FAQ before you post to Usenet?  If not please do so in
: future.  If, on the other hand, you have *considered* reading the FAQ

Actually it was a brief moment of stupidity caused by the mental anguish
of seeing all of my programs segfault time and time again. :)  I
apologize -- however the memory leak thing was just a guess as to what
may be going on; actually I was looking for some kind of suggestions
as to why my computer occasionally won't run anything.. Looking back
I think I left that part out of the original message.. Anyways, the
Linux Faq doesn't have anything so general as "Why does my computer
suck", though I suspect I don't have enough virtual ram or I've got some
kind of problem with my kernel...  [Oddly, I don't detect Linux
ever swapping when my system starts to crash, so perhaps it's not
memory...<shrug>]

--

           'O, there has been much throwing about of brains.' -ws

Quote:> I set the proper options in the makefile, and then do a make.

> The first 3 or 4 C files are compiled, and then I get a core dump.  
> erratic manner.  Sometimes make itself dies, while other times I get
> "gcc: caught SEGV" or something to that effect.  A couple times after a
> The make never dies in the same place though.
> Id1 is cycling too fast; disabling access for 5 minutes
> [I don't recall exact text, but it refers to too many login failures
>  for a console window]

---

 Wasatch Communications Group               http://www.wasatch.com

: Could you give a better description of the symptoms?  What do you mean
: "won't run anything".  Does it boot? If so, it's running a dozen
: different things.

It runs things, just not enough things to be of use.  As an experiment I
went ahead and redid the whole install so that now I have 48 megs ram + 50
swap, which imo is a very big ceiling, and hopefully should rule out the
idea of memory problems.  I installed the regular redhat 4.0 distribution
once more, along with enough stuff to do basic C development.

Everything to this point seems to be going fairly smoothly, so I download
the source to tin and am going to compile it.

First I reboot, then log in as root.  So the only currently running processes
are sendmail, gpm, the various logging daemons and whatever else is run in
the stock kernel (and the root shell).

Next I run free real quick to see how I'm doing on ram; I have 40 megs
available or so, and none of my swap is in use.

I set the proper options in the makefile, and then do a make.

The first 3 or 4 C files are compiled, and then I get a core dump.  I run
make again, and it picks up where it left off.  This continues in a very
erratic manner.  Sometimes make itself dies, while other times I get
"gcc: caught SEGV" or something to that effect.  A couple times after a
"make clean" it would do the entire compile-link process without a hitch.
Other times (more often) there is a point where everything dumps core.
For instance I got to a point where make failed because of an error in the
Makefile, so I do "vi Makefile" and get a message from vim that it had
a segmentation fault.  Any further attempts to launch vi are unsuccessful
until a reboot.  Then, running "make" will also dump core, as will running
just about anything else.  The make never dies in the same place though.

[running free again reflects I have tons of available memory and my swap
 drive is still untouched]

As an aside, Linux also occasionally pops me into a screen where it says

Id1 is cycling too fast; disabling access for 5 minutes
[I don't recall exact text, but it refers to too many login failures
 for a console window]

But it prints this message for all 7 consoles, when I'm not even attempting
to login.  [IIRC, it happens after I log out sometimes]

--

           'O, there has been much throwing about of brains.' -ws

IF someone added memory testing to the Linux kernel this problem would
be a lot more visible.

But, as a quick way of diagnosing this, try:
        swapoff -a
        and then to the compile.
try the compile multiple times until failure or it succeeds say, five times..

The thing that gave me sporadic lockups was a problem in my swap partition
(I was using a Western Digital drive - that says it all ).

If it is memory (determined by getting errors with swap off).  Then you
have to deal with a number of possibilities, including CMOS chipset timing
options, bad SIMMs, bad cache..  CHeck the signal 11 FAQ ( there should be
a pointer to it somewhere, or a do a netsearch . I lost my bookmarks file ).

--
Jon Martin Solaas