Re: Problems with shared arena

New Message Reply Date view Thread view Subject view Author view

From: howxn++at++ivlab.com.sg
Date: 02/16/2001 03:21:21


Hi all,

thanks for the reply!

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.

Xian Neng

>Hello There !
>
>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
>> >> -----------------------------------------------------------------------

>> >> List Archives, FAQ, FTP: 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
>> >>
>> >
>> >
>> -----------------------------------------------------------------------
>> List Archives, FAQ, FTP: 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
> \__ \__ \____\__ \__ http://reality.sgi.com/yair
> \__ \__ \__ Work: (650) 933-6502
> \__ \__ \__ Home: (408) 226-9771
> \__ \__ \__
>
>


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Fri Feb 16 2001 - 03:21:24 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.