From: Yair Kurzion (yair++at++polygon.engr.sgi.com)
Date: 04/23/2002 15:31:35
Hello Dimi !
I can not reproduce the memory leak you reported. Could you please send me a
small sample showing the leak ?
The code in pfuNewSharedTex doesn't increment the ref-count of the allocated
pfTexture. This can cause all kinds of problems when you delete such
pfTextures. I tried two variations on pfuNewSharedTex (added a pfRef) and none
of them leaked memory:
Here's the bottom part of the function (change the #if value to try the two
variations):
if (!ntex)
ntex = pfNewTex(arena);
#if 0
if (pfLoadTexFile(ntex, (char *)filename) > 0)
{
tex = pfNewTex(arena);
pfCopy(tex, ntex);
pfAdd(*texList, tex);
pfRef (tex);
return tex;
}
#else
if (pfLoadTexFile(ntex, (char *)filename) > 0)
{
tex = ntex;
pfAdd(*texList, tex);
pfRef(tex);
ntex = NULL;
return tex;
}
#endif
return NULL;
}
I modified the program /usr/share/Performer/src/pguide/libpf/C/deleteTBox.c
to call pfuNewSharedTex instead of pfNewTex (Also had to call pfuInit). My
modified program works fine with any of the above variations (no leaks).
-yair
> I am still "fiddling around" with dynamic loading of Scene graphs :),
> and I have come around another strange problem.
> First thank you for your previous replies concerning deleting pfFluxes.
> They were very helpfull.
>
> What I run now into is that I have a class which creates billboards
> (using pfBillboard) and loads up the textures which are mapped onto that
>
> billboards. I load the textures using the pfNewSharedTex function, in
> order
> to optimize pfTexture usage.
> Strangely I noticed that there was a big memory leak whenever I used
> that function.
> When I used the loadFile member function of a previously created
> pfTexture ther was no memory leak.
> Fortunately this function belongs to the pfu... classes of performer
> which are open source.
> So I went inside the pfuTex.c file (which had the function) and tried to
> find the memory leak.
>
> I found that the leak was occuring when a pfCopy was invoked inside the
> pfNewSharedTex
> function. The original algorithm used was:
> The function first allocates a static pfTexture object (I dont know
> why).
> Then loads the image file into that object (using pfLoadFile).
> If all went OK, it created a new pfTexture and used pfCopy to copy the
> static object
> onto the new one.
> After that it added the new one to the internally holded list and
> returned it.
> Changing the algorithm a bit (essentially removing the pfCopy) stoped
> the leak.
>
> I know it makes no sense that a pfCopy should produce a memory leak,
> maybe its another performer bug.
> I verified this by minitoring the shared arena usage and using
> gmemusage.
>
> Is there anything I dont take into account, or is it a real performer
> bug.
> Hope you can help me.
>
> Dimi
>
>
> --
> Dimi Christopoulos {christop++at++fhw.gr}
> VR Software Engineer
> Foundation of the Hellenic World
> Athens - Greece
>
>
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>
--
\_________ \_____ \__ \__ \_____
\_________ \_____ \__ \__ \_____ Yair Kurzion
\__ \__ \____\__ \__ yair++at++sgi.com
\__ \__ \__ (650) 933-6502
\__ \__ \__
\__ \__ \__
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 15:32:17 PDT