Segment violation from malloc (what does it mean?)

[Polar Humenn]

In article <1063 at brchh104.bnr.ca> fredc at umrisca.isc.umr.edu writes:

>I have been working on a big SunView program for a while now, and, after
>adding some [more] dynamically allocated data structures which endure for
>the entire program, dbxtool gave me the following message:
>
>(dbxtool) Running: sym_edit 
>signal SEGV (no mapping at the fault address) in malloc at 0xec52864
>malloc+0xe4:		movl	a5@(0xd4),a0
>
>A little background here might be helpful.  I'm running on a diskless 3/60
>under 4.0.3.  The program has a lot of stuff stored in linked lists for
>easy loop-induced extraction (when you come to a NULL pointer, you're at
>the end of the list), and for easy addition to the lists' contents (with a
>static array, the declaration must be altered when adding to the list).

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.

>What I want to know is: does this message mean I am running into a limit
>on my dynamic storage space?  

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.  If it can't, you're
   out of luck.  This almost means you need twice the swap space for your
   program, because of the copy to the newly allocated space.

>If so, is it a hardware or un-fixable
>software limit, or can I get the compiler to give me a larger heap to work
>with?

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.