Acosta, Mark W (acostmw++at++texaco.com)
Fri, 20 Aug 1999 10:48:33 -0500
If attribute and index lists are allocated from the pfMalloc routines,
pfGeoSet::setAttr will correctly update the reference counts of the
lists. Specifically, pfGeoSet::setAttr will decrement the reference
counts of the old lists and increment the reference counts of the new
lists. It will not free any lists whose reference counts reach 0.
So, you'll have to get the old list, set the new list, and pfDelete the old
list.
I feel your pain. It can be really hard to find things in the Performer man
pages. Good luck.
Mark Acosta
Texaco
-----Original Message-----
From: Joshua Shagam [SMTP:jshagam++at++d-a-s.com]
Sent: Friday, August 20, 1999 9:59 AM
To: info-performer++at++sgi.com
Cc: gets-team++at++d-a-s.com
Subject: Help needed wrt apparent memory leak in IRIS
Performer 2.2
I am having a problem with what appears to be a memory leak in IRIS
Performer; namely it seems to not be properly freeing memory in the
shared memory arena. As I have a large number of pfGeoSets which
need
to constantly change size (we are dynamically retesselating a
terrain
mesh and have to work with pre-existing pfGeoSets, due to the
client's
requirements), I am having to constantly pfMalloc the pfGeoSets'
attribute lists, and make use of Performer's garbage collection
(pfFlux
apparently can't deal with allocations which change size). It all
works
well and good for several minutes, after which I get an error that
the
memory in the shared memory arenas have been exhausted. Now, I know
that by this point the respective attribute lists aren't even close
to
filling up the shared memory arena, and although there's bound to be
quite a bit of fragmentation it's not possible that the attribute
lists
are even taking up 64MB of memory (the arena is at the default size
of
256MB).
Are there any known bugs/workarounds regarding Performer's garbage
collection? Also, is there something I need to do to explicitly
cause
the GC to sweep any zero-refcount memory? I've checked to make sure
that the old attribute lists' refcounts are zero, and so when I
rebind
them (with pfGSetAttrList) they *should* be getting freed, but I
don't
think the heap is being maintained properly on Performer's side.
Another indication that the heap is having trouble is that before I
used
constant pfMalloc()s as a replacement for pfFlux, I set Performer up
to
only use a single processor (just for testing purposes, as we
require
multiprocessor support), and just used pfRealloc() on the attribute
lists. After a comparable amount of time, the program would crash
with
the same error (namely that the arena was filled up). So again, I
think
the problem is in Performer's garbage collection, or perhaps there's
some function I need to be calling in order to activate the garbage
collector; I've not yet found one, however, no matter how much I
read
and reread the online Performer documentation.
Any help you could give me would be greatly appreciated. Many
thanks in
advance.
-----------------------------------------------------------------------
List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Fri Aug 20 1999 - 08:53:17 PDT