roy@phri.UUCP (Roy Smith) (11/09/87)
I'm writing a program which uses malloc on a Sun-3 running
SunOS-3.2 and getting unexplicable segmentation violations. Using Brandon
Allbery's malloc debugging package and dbx, I've found the offending line,
but I still can't figure out why it bombs.
From dbx I see:
[many similar getmem/malloc calls deleted]
calling getmem(nbytes = 3) from function storeseq
calling malloc(n = 3) from function getmem
called malloc(0x3(3))
returning 0x8fffc "" from malloc
returning 0x8fffc "" from getmem
signal SEGV (segmentation violation) in storeseq at line 97 in file "mem.c"
97 *(t++) = *(old++);
(dbx) print old
`mem`storeseq`old = 0xefffc10
(dbx) print t
t = 0x90004
Getmem is just a stub which passes its argument to malloc and
returns what malloc does. The code around line 97 is (seq_t is typedef'ed
as int):
/*
* Storeseq() -- store a sequence.
*/
seq_t *storeseq (old)
seq_t *old;
{
seq_t *new;
register seq_t *t;
char *getmem();
/* NOSTRICT */
if ((new = (seq_t *) getmem (seqlength (old) + 2)) == NULL)
xerror ("storestr(): out of memory (%s)", old);
t = new;
*(t++) = *(old++);
while (*old != NULL)
*(t++) = *(old++);
return (new);
}
Aparantly something magic happens when I pass the 0x90000 memory
boundary. I don't think I'm out of swap space or hitting a resource limit.
Besides, anything I could imagine which wouldn't let me allocate memory
past that point should cause malloc itself to fail and return NULL instead
of an ostensibly valid pointer to memory I can't use. So, why the magic
wall at 0x90000? Personally, I can't think of any explanation other than a
bug in malloc(); somebody tell me it isn't so.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016