Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.unix.wizards
Subject: question about malloc on Sun-3
Message-ID: <3015@phri.UUCP>
Date: Sun, 8-Nov-87 19:51:17 EST
Article-I.D.: phri.3015
Posted: Sun Nov  8 19:51:17 1987
Date-Received: Wed, 11-Nov-87 03:06:35 EST
Organization: Public Health Research Institute, NYC, NY
Lines: 58


	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