From: Yair Kurzion (yair++at++polygon.engr.sgi.com)
Date: 02/20/2001 14:55:08
Hello Xian !
> After seeing your reply I decided to thoroughly look through my own channel
> draw callbacks, and I think I found the problem.
> my draw callback looks something like that:
>
> int
> drawFunc(pfChannel * chan, void * data )
> {
> pfFog * fog = new pfFog();
> ....
>
> pfEnable(...)
> fog->apply();
> pfOverride(...)
>
> pfDraw();
> pfDelete( fog );
> }
>
> Apparently it's the pfFog that causes the problem. It seems that pfDelete doesn't
> clean up the memory properly. I took out the pfFog then the memories become
> stable.
>
> Although I am still curious why pfDelete doesn't work, I am now able to solve
> the problem and finish my project. Thanks again.
I tried to replicate your fog-related memory leak by modifying the complex.c
DRAW callback. My code (below) does not leak any memory.
Perhaps your DRAW callback increases the ref-count of your fog object by adding
it to some pfGeoState. If it does, then pfDelete will not delete it (and it
would explain your memory leak).
My modified DRAW callback looks like:
static void
DrawChannel (pfChannel *channel, void *data)
{
pfFog *fog;
(channel, data);
fog = pfNewFog (pfGetSharedArena());
pfFogType (fog, PFFOG_VTX_LIN);
pfFogColor (fog, 1.0, 1.0, 1.0);
pfFogRange (fog, 0.5, 20.0);
pfApplyFog (fog);
pfEnable (PFEN_FOG);
pfOverride(PFSTATE_FOG | PFSTATE_ENFOG, PF_ON);
/* rebind light so it stays fixed in position */
pfLightOn(Sun);
/* erase framebuffer and draw Earth-Sky model */
pfClearChan(channel);
/* invoke Performer draw-processing for this frame */
pfDraw();
/* draw Performer throughput statistics */
if (Shared->drawStats)
pfDrawChanStats(channel);
/* read window origin and size (it may have changed) */
pfGetPWinSize(pfGetChanPWin(channel), &Shared->winSizeX, &Shared->winSizeY);
pfDelete (fog);
}
I used this function for printing the status of the shared arena (called in
the APP, before pfSync):
void print_arena_info (void)
{
static int max_used = 0;
int used;
struct mallinfo mem_info;
mem_info = amallinfo( pfGetSharedArena() );
fprintf( stderr, "\n\n=================================================\n");
used = pfGetMemoryArenaBytesUsed();
if (used > max_used)
max_used = used;
fprintf(stderr, "Arena Bytes Used: %d, Max: %d\n", used, max_used);
fprintf(stderr, "Arena space: %d in use: small: %d ordinary: %d\n",
mem_info.arena, mem_info.usmblks, mem_info.uordblks );
mem_info = mallinfo( );
fprintf(stderr, "Regular space: %d in use: small: %d ordinary: %d\n",
mem_info.arena, mem_info.usmblks, mem_info.uordblks );
fprintf( stderr, "=================================================\n\n");
fflush (stderr);
}
-yair
> >Performer 2.2 is out there for quite a while now. I haven't seen any problems
>
> >like that one you describe.
> >
> >Do you have any DRAW callbacks ?
> >
> >Can you run your pfb file with no callbacks in perfly ? Does it still leak
> ?
> >
> >Can you send me the smallest sample (code/model) that leaks memory ?
> >
> >Thanks,
> >-yair
> >
> >> We are using Performer 2.2.
> >>
> >> >
> >> >We've taken pains to avoid allocating any memory in the draw process, so
>
> >> >it looks like you may have found a bug. Which version of performer are you
>
> >>
> >> >using?
> >> >
> >> >-- Marcin
> >> >
> >> >On Tue, 13 Feb 2001 howxn++at++ivlab.com.sg wrote:
> >> >
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I have a question on how the shared arena is working.
> >> >>
> >> >> i) Does the draw traversal allocate memory into the shared arena each
> time
> >> it
> >> >> is executed? Is it a standard action of performer?
> >> >>
> >> >> ii) If not, is there anything to avoid such action?
> >> >>
> >> >> iii) Is there any function to clear the shared memory apart from pfDelete?
>
> >>
> >> >>
> >> >> My scenario is this: I am running on an IRIX64 6.5 machine, n32 programs,
>
> >> with
> >> >> quite a huge database. The machine has 4 processors and I used PFMB_DEFAULT
>
> >>
> >> >> for the multiprocess. I used pfb loader to load all my models at initialization
>
> >>
> >> >> times, and apply switch nodes for each model for different settings. By
> using
> >>
> >> >> the software(arena_debug) by Ran Yakir(thanks!), I noticed that each frame
>
> >> the
> >> >> program (the draw process) is allocating some memory into the shared arena,
>
> >>
> >> >> thus causing the memory to increase slowly, and eventually the program
> terminates
> >>
> >> >> due to insufficient shared arena size.
> >> >>
> >> >> I need urgent help on this, so any suggestion to remedy this situation
> will
> >>
> >> >> be greatly appreciated.
> >> >>
> >> >> Xian Neng
--
\_________ \_____ \__ \__ \_____ Yair Kurzion
\_________ \_____ \__ \__ \_____ yair++at++sgi.com
\__ \__ \____\__ \__ http://reality.sgi.com/yair
\__ \__ \__ Work: (650) 933-6502
\__ \__ \__ Home: (408) 226-9771
\__ \__ \__
This archive was generated by hypermail 2b29 : Tue Feb 20 2001 - 14:55:15 PST