fredc@umrisca.isc.umr.edu (01/05/91)
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). What I want to know is: does this message mean I am running into a limit on my dynamic storage 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? Fred Clauss INTERNET: fredc@isc.umr.edu (preferred) P.O. Box 815 or fredc@ee.umr.edu Rolla, MO 65401 BITNET: S081192@UMRVMA phone: (314)364-7224
henry@zoo.toronto.edu (Henry Spencer) (01/08/91)
In article <1063@brchh104.bnr.ca> fredc@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: > >signal SEGV (no mapping at the fault address) in malloc at 0xec52864 A segmentation violation in malloc almost invariably means that you have corrupted its data structures. Ways of doing this include, depending on circumstances and system variant: freeing something that was not malloced, freeing NULL, freeing something twice, writing past the end (or beginning) of a malloced area, writing into an area that was malloced but has been freed, and writing into memory at random (typically due to garbaged pointers or grossly out-of-bounds array subscripts). >What I want to know is: does this message mean I am running into a limit >on my dynamic storage space? ... Almost certainly not. That should just give you a NULL return value. A program bug is much more likely. If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
polar@top.cis.syr.edu (Polar Humenn) (01/08/91)
In article <1063@brchh104.bnr.ca> fredc@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.
gld@cunixd.cc.columbia.edu (Gary L Dare) (01/10/91)
polar@top.cis.syr.edu (Polar Humenn) writes: |fredc@umrisca.isc.umr.edu writes: |> |>(dbxtool) Running: sym_edit |>signal SEGV (no mapping at the fault address) in malloc at 0xec52864 |>malloc+0xe4: movl a5@(0xd4),a0 | |>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. Also, a few strategically free() operations might be in order to clear off your heap. Otherwise, stuff you've declared for one-shot use will stick around after you've exited your routine. Gary L. Dare gld@cunixD.cc.columbia.EDU
guy@uunet.uu.net (Guy Harris) (01/11/91)
>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.