Subject: Re: Xsun memory leak?
To: Chuck Silvers <chuq@chuq.com>
From: David Brownlee <abs@anim.dreamworks.com>
List: port-sparc
Date: 05/06/1998 10:23:15
	Does the machine need to be running a -current to work?
	compiling it on a 1.3.1 box gives:
mmalloc.c: In function `mmalloc_find':
mmalloc.c:33: warning: assignment makes pointer from integer without a cast
mmalloc.c:35: `next' undeclared (first use this function)
mmalloc.c:35: (Each undeclared identifier is reported only once
mmalloc.c:35: for each function it appears in.)
mmalloc.c:35: warning: assignment makes pointer from integer without a cast

	Hmm.. I can't find the LIST_FIRST or LIST_NEXT macros on either
	a 1.3.1 or -current tree... What am I doing wrong!? :)

		David/absolute

 -=-  "I know its not the right thing, and I know its not the good thing"  -=-

On Wed, 6 May 1998, Chuck Silvers wrote:

> my theory on this was that it was horrible memory fragmentation
> caused by netscape displaying lots of images of widely varying size,
> and the system malloc not dealing with this particularly well.
> I hacked up a version of malloc() that uses mmap() to satisfy
> requests of more than pagesize, which has the advantage that
> freeing these blocks with munmap() will actually release the
> memory back to the system.  this is at
> 
> 	http://www.chuq.com/netbsd/mmalloc.tar.gz
> 
> to build, copy netbsd's src/lib/libc/stdlib/malloc.c into the
> mmalloc directory and "make".  to use, install the resulting
> shared library somewhere and setenv LD_PRELOAD to point to it.
> I only use it for my X server (via a .xserverrc), but it
> should work for everything.
> 
> I haven't had my X server die from lack of memory since then,
> but then I've added more RAM and swap to my machine also,
> so I'm not sure which is responsible.  it was a fun hack
> either way.  one funny side-effect of this is that memory
> allocated with mmap() doesn't show up in ps, so it's hard
> to tell how much memory the process is really using anymore.
> I wrote another little program to dump a process's vm_map
> via /dev/kmem, but the output isn't so useful since it's hard
> to tell what's what.
> 
> -Chuck