lkml.org 
[lkml]   [1998]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: when out of memory, random programs die
On Tue, 8 Dec 1998, Steven N. Hirsch wrote:

>
>
> On Mon, 7 Dec 1998, Adam Heath wrote:
>
> > System stats:
> > k6-2-332.5, 128m ram, 256 swap, 2.1.105.
> >
> > I did a 'time make -j zImage modules' on 2.1.131ac4 to test my system out
> > today, and relatively early random gcc's, cpp's, and make's started dying. No
> > other program anywhere was killed, only the ones involved in this compile run.
> > What was odd, was that the top level make was killed, so the other makes kept
> > running in the background. a killall make helped that on another console, but
> > shouldn't the kernel kill child processes first, before parents in low-mem
> > situations? or at least make it a sysctl option.
>
> Are you using egcs? On a Cyrix P150+ box here it is unusable, segfaults,
> SIGILL, SIGSEGV, you name it! I've noticed this from time to time over
> the past few egcs revisions; they seem to antagonize some bug in the Cyrix
> microcode. If I switch to gcc-2.7.2 it works fine.

No. And note, other progs running do NOT die. X doesn't. Netscape doesn't.
None of my daemons. -j 50 did run to completion fine. On 105, it took the
kernel 10m30s to compile 131ac4(don't remember the -j factor). On 131ac4,
with -j50, it took 10m to compile 131ac4.

> On my dual PPro SMP machine, the same egcs executables are flawless. I've
> seen other reports of this Cyrix strangeness, and wonder if you aren't
> seeing something like it, but with AMD flavoring.

I have no prob with the kernel killing random programs. But they should be
programs that have no children at all. Kill the ones farthest down from init.

Adam



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.037 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site