Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!ucsd!hub.ucsb.edu!appmag!pa
From: pa@appmag.com (Pierre Asselin)
Newsgroups: comp.unix.aix
Subject: malloc (was: making a request to IBM)
Summary: it's not a bug, it's a feechur
Keywords: malloc psalloc paging space
Message-ID: <1991Apr9.024814.1141@appmag.com>
Date: 9 Apr 91 02:48:14 GMT
Organization: R&D, Applied Magnetics, Goleta, CA
Lines: 59

The problem:  as you all remember,  malloc()  returns  NULL  only
when the process exceeds its datasize limit.  If malloc returns a
non-null pointer, the memory  may  turn  out  to  be  exceedingly
virtual:   there  won't  be any paging space behind it.  AIX runs
out of paging space when the process actually  uses  the  memory.
Various  processes  die.   In Info, see `List of Books', `General
Concepts  and  Procedures',  scroll  ~1/3  down,  `Paging   Space
Overview'.  See also psmalloc.c in /usr/lpp/bos/samples.  Etc etc
etc.

Personally, I think it's a bug.  If  there  is  no  memory  left,
malloc  should  return  a  NULL.  IBM says it's a feature,  catch
SIGDANGER if you don't like it.  At  least  one  person  at  SDRC
agrees with me:

> IBM RS/6000 Memory Allocation Problem           September, 1990
>
> ...The operating system on the IBM RS/6000 allows CAEDS to
> allocate more  memory  than  is  actually  available...

Now, we meet with IBM representatives every Thursday so that  all
our  problems  may get solved.  At those meetings I am encouraged
to report these things  to  IBM,  even  if  they  involve  design
changes.  (This is where the `design APAR' mythology started.  As
pointed out later on comp.unix.aix, there is no such thing  as  a
design APAR.)

The predictable result came out today.
1) It's not a bug.  It's a feature.  Therefore, there is no problem.
2) If I want a change, I am to file a `DCR' with my
   marketing representative.
3) This behaviour of malloc is an IBM design and was not
   mandated by an external standard such as SVID.

The only interesting piece of information is (3).
General conclusion from this exercise:

 o  IBM doesn't listen.  It doesn't know how.
 o  IMB doesn't respond with accurate information either.
    It doesn't know how.

General conclusions from earlier exercises:

 o  Software Defect Support is officially limited to its narrow mandate.
 o  Technical support is available for the RISC-6000's.
    It's called comp.unix.aix.
 o  Accurate information on the RISC-6000's is available, but only
    on comp.unix.aix.
 o  Accurate information on the IBM support structure is available,
    but only on comp.unix.aix.
 o  To this day, IBM is convinced that it's doing a fine job.
 o  Hardware support does work.  Beats me.

Austin:  STAY ON THE NET!  You're the only way we'll ever get the
straight dope.  (Anyone care to give us the straight dope on this one?)

Good day.

  --Pierre Asselin, R&D, Applied Magnetics Corp.  I speak for me.