Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!stroyan
From: stroyan@hpfcdc.HP.COM (Mike Stroyan)
Newsgroups: comp.sys.hp
Subject: Re: Freeing memory in starbase Display Lists
Message-ID: <5570274@hpfcdc.HP.COM>
Date: 20 Aug 89 20:55:48 GMT
References: <1035@esatst.yc.estec.nl>
Organization: HP Ft. Collins, Co.
Lines: 37

> Maybe I'm doing something wrong, but if I create a display list,
> delete it using delete_all_segments then recreate exactly the same
> list, the process size increases. Has this anything to do with the
> fact that I'm not using -lmalloc. I can't use this since I'm using the
> X toolkit in the same program and XtMalloc chokes when -lmalloc is
> used.

You certainly seem to be doing something different.  The product test
suite does verify that all malloc's are balanced by free's.  A simple
test I ran checking sbrk(0) results showed perfect reuse with and
without linking in -lmalloc.

Without more information I'm pretty well restricted to taking shots in
the dark, but here are a few possibilities.

- There is some element sequence in your segments that isn't freed
  correctly by delete_all_segments.

- Your delete_all_segments call has the wrong file descriptor.

- The display list malloc areas are intermixed with Xt malloc areas,
  and memory framentation is taking up more space when allocating
  around the other malloc areas.

- The malloc free list is getting trashed by code writing outside of a
  malloc area.  This possibilty is made more likely since you said that
  "XtMalloc chokes when -lmalloc is used".  The -lmalloc library works
  fine for me with Xt.  The two malloc libraries produce different
  amounts of padding and different results when memory outside of malloc
  areas becomes trashed.  The usual result of this is a segment fault,
  but more subtle effects are possible.

- There was a memory leak problem with -lmalloc that was fixed in the
  6.5/3.1 releases.  There may be some similar problem with libc malloc
  that shows up in your circumstances.

Mike Stroyan, stroyan@hpfcla.hp.com