Bug 50252 - Any user process can crash the 2.4.3-12enterprise kernel when virtual memory exceeds RAM + swap. The crash is indicated by infinitely looping identical
Any user process can crash the 2.4.3-12enterprise kernel when virtual memory ...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i686 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-29 01:15 EDT by Need Real Name
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-07-29 01:15:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22enterprise i686)

Description of problem:
A simple test program that calls malloc() and dirties buffers can crash the
RH7.1 update kernel 2.4.3-12enterprise on the 2nd or 3rd try.  The test
program has successfully brought the server to its knees when run by root
or by nobody.  The unsuccessful attempts result in a single console message
such as:

Out of Memory: Killed process 818 (growmem).

However when the test program causes the kernel to crash, the message is
repeated ad infinitum:

Out of Memory: Killed process 819 (growmem).
Out of Memory: Killed process 819 (growmem).
Out of Memory: Killed process 819 (growmem).
Out of Memory: Killed process 819 (growmem).
...

When the server crashes, even ctrl-alt-delete doesn't work.

I have verified that this simple test program also crashes the latest
rawhide kernel 2.4.6-2.4enterprise.  In the latter case no message is
printed.  Instead the kernel deadlocks silently.   (Use a test case of
"./growmem 1000000 1000 10").

Here is the test program:

// growmem.c written by Stephen Heise <bugzilla@streetprices.com>
28/Jul/2001
// compile me with "gcc -o growmem growmem.c"
// run me with instances such as "growmem 2000000 1000 100"
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
  int chunksize,numloops,us_delay,i,j;
  void *r;

  if (argc != 4)
  {
    printf("Usage: %s <chunksize> <numloops> <delay_in_us>\n",argv[0]);
    return(1);
  }

  chunksize=atoi(argv[1]);
  numloops =atoi(argv[2]);
  us_delay =atoi(argv[3]);

  for (i=1; i<=numloops; i++)
  {
    r=malloc(chunksize);
    if (!r)
    {
      printf("Malloc failed on loop %d/%d (%iMB allocated so far)\n",
        i,numloops,(int)(chunksize/1024.0/1024.0*i));
      return(1);
    }
    for (j=0; j<chunksize; j+=4096)
    {
      *(char *)(r+j)=0;
    }
    usleep(us_delay);
  }

  return(0);
}

Description of Testbed System Used:
System A: Intel STL2 Board w/ Dual 1 Ghz Processors and 512MB ECC PC133
RAM.
System B: Intel L440GX Board w/ Dual 1 Ghz Processors and 512MB ECC PC100
RAM.


How reproducible:
Sometimes

Steps to Reproduce:
1. while [ 1 ]; do ./growmem 2000000 1000 100; done   # Wait about 60
seconds on 2.4.3-12enterprise.

or
 
1.  while [ 1 ]; do ./growmem 1000000 1000 10; done  # Wait about 60
seconds on 2.4.6-2.4enterprise.

Actual Results:  Out of Memory: Killed process 819 (growmem).
Out of Memory: Killed process 819 (growmem).
Out of Memory: Killed process 819 (growmem).
(ad infinitum, synonymous with kernel deadlock)


Expected Results:  Malloc failed on loop 153/1000 (291MB allocated so far)



Additional info:
Comment 1 Need Real Name 2001-08-08 19:25:44 EDT
I have observed that the official kernel.org 2.4.8-pre5 release no longer has
this serious memory management flaw.
Comment 2 Bugzilla owner 2004-09-30 11:39:06 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.