Marcus Barnes (marcus++at++multigen.com)
Fri, 18 Apr 1997 11:49:34 -0700
Yes. It's also important to note that pfScene, pfSCS, pfDCS, and pfGeode are
derived from pfNode which adds addtional ctor/dtor behavior.
> and, hence, pfMemory and will be deleted when I do a pfDelete
> on the lower pfSCS.
This is true as long as pfMemory::getRef() <= 1 for all those pfObject's. Since
pfTexture and pfGeoState objects are generally shared between pfGeoSet's, it's
likely that they will not be deleted. Rather their ref. counts will be
decremented because the pfGeoSet gets deleted. It's possible that the
pfGeoState will be deleted but not the pfTexture for similar reasons.
> (I explicitly pfDelete the pfDCS and upper pfSCS for other reasons.) These
> objects are all created for this one object so there should be no other
> references to them.
Yes, if this is true then they will all be deleted.
> The coordinates, normals and color of the pfGeoSets are pfVecs and these are
> NOT derived from pfMemory.
... pfdGeoBuilder creates them in pfMemory's.
> I think that if I want them to be deleted, I need
> to allocate them with pfMalloc instead of new, e.g.
>
> pfVec3 *sidecoords = (pfVec3 *)pfMalloc( 20*sizeof(pfVec3),
pfGetSharedArena()
> );
This is the accepted method. Note that in this case pfVec3::pfVec3() has not
been called. Your vectors are not properly constructed. This may be okay if you
are going to set all the values yourself.
> instead of
>
> pfVec3 *sidecoords = new pfVec3[20];
Note that the problem here is that you are calling ::operator new[](size_t)
which is not overloaded by Performer to place objects in shared memory. In
general, Performer does not support shared memory arrays of C++ objects.
You could have arrays if you define ::operator new[](size_t,void*). It's
defined by the 7.1 compiler. This idiom should work (I haven't tried it myself)
to allocate the array, BUT ... :
pfMemory* mem = new ( 20 * sizeof(pfVec3) ) pfMemory;
pfVec3* sidecoords = new ( mem ) pfVec3[ 20 ]; // placement ::operator new[]()
... even if this does work you _cannot_ use it! This is because Performer
whould never know to call "delete [] sidecoords". Therefore
pfMemory::checkDelete( sidecoords ) is an error and yet that is what must work
in order to support arrays in Performer. The lesson is "if you cannot properly
destroy each element of an array then you shouldn't create such an array."
> The image data in the pfTexture also needs to be allocated with pfMalloc if I
> want it automatically deleted.
pfTexture::loadFile() does this for you.
> As it happens, the function that builds this pfGeode gets an image passed in
> that was not allocated with Performer. I've tried two approaches here. One
> is to pfMalloc space for the image and make a copy of it. This copy is used
> in setImage. I expect the pfDelete on the pfSCS to take care of deleting
> this. (I independently take care of deleting the original image.)
This should work.
> The second approach I take is to use the original image in setImage. In this
> case I don't expect pfDelete to do anything to it since it's not pfMemory.
But
> I do take care of deleting it explicitly myself.
This is fine too.
> Are my expectations here correct? Do I have the right impression about
what's
> supposed to be getting deleted and what I have to do to make it work?
Yeah.
> What concerns me here is that my memory leak behavior is very different
> (reduced) when I simply comment out the code that creates the pfTexture and
> attaches it to the pfGeoState.
Assuming you've got it right, it's possible that Performer is leaking texture
related memory or that the GL is leaking memory. This all depends upon the
software versions though. I've tested scene graph memory leakage a fair amount
over the years and I don't remember pfTexture leakage at any time.
Regards.
--
+ Marcus Barnes, Technical Staff mailto:marcus++at++multigen.com +
+ Multigen Inc. http://www.multigen.com +
+ 550 S. Winchester Blvd. phoneto:1-408-556-2654 +
+ Suite 500 San Jose CA 95128 faxto:1-408-261-4102 +
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:55:05 PDT