🚀 go-pugleaf

>There are two possiblities, maybe more :-<, however, these are problems I
>ran into while writing SunView programs.  The obvious one is:
>
>1. You messed up the heap in some way, ie. wrote where you shouldn't have.
>   Malloc is suppose to return NULL when it knows something is wrong with the
>   heap.  It's not all that smart.

But if you use the debugging version - see MALLOC(3) - it can be told to
do more checking of that sort.

>2. In short, yes.  The swap space on your partition is not big enough.
>   These SunView programs require much memory, as I found out.  Every time
>   malloc executes a sbrk() the operating system looks for a contiguous swap
>   space to fit the entire data segment of the program.

Umm, no, it doesn't; he said he's running under 4.0.3, and 4.x doesn't
allocate big continuous chunks of address space.

What's more, there's no evidence from what the original poster said that
indicates that he *is* running out of swap space; running out of swap
sapce causes the aforementioned "sbrk()" to fail, which causes "malloc()"
to return NULL.  It seems more likely that either 1) there's a bug in
"malloc()" that corrupted the heap or 2) there's a bug in his program that
corrupted the heap.

>   This almost means you need twice the swap space for your
>   program, because of the copy to the newly allocated space.

What copy?  Even SunOS releases prior to 3.x didn't allocate one
contiguous chunk for the entire data segment.

>Get a larger swap space.  If your admistrator has extra space he may
>arrange a "swapfile" for you.  However, I'm not really sure if this is
>possible on a diskless client.  

It sure *is* possible on a 4.x diskless client - the only thing such a
beast *can* swap to is a "swapfile" over NFS!  Your administrator can make
the client's swap file bigger, if necessary - but so far, it's not clear
that it's necessary, given what the original poster said.