Mark Lewis (MarkL++at++equipe.ltd.uk)
Tue, 13 Apr 1999 08:02:23 +0100
I went through this loop some time ago, and eventually fixed it. One
debug aid I used was to actually do the paging in the APP and call
pfDelete instead of pfAsyncDelete. You can then check the return code,
and find out more about what is going on.
Hope this helps.
Mason D. Menninger wrote:
>
> I am working on an application that pages in tiles representing
> the surface of the earth based on the proximity of the user's
> viewpoint. The paging is successful, but the size of the application
> jumps about a megabyte (according to "gmemusage") per paging
> occurrence. I have narrowed the problem down to the pfBufferAddChild
> and pfAsyncDelete calls. I am quite certain that pfBufferRemoveChild
> and pfAsyncDelete are called for each child in the DCS (I am attempting
> to remove them all at this point). Of course, pfAsyncDelete does
> not provide a mechanism for indicating if the node was actually
> removed so I am not assured that it is really working. In fact,
> removing the pfAsyncDelete call altogether appears to have no effect
> on memory usage (it doesn't make things worse).
>
> Unfortunately, this is more than a mere annoyance. The application
> is required to orbit the earth and page in quite a few (possibly
> hundreds) of tiles per session. It inevitably runs out of memory
> and crashes before completing the full task.
>
> I am developing on an 8 processor, 3 pipe Onyx 2 with 1 Gig main
> memory. The program is compiled under Irix 6.5.3 with Performer
> 2.2.4 libraries.
>
> I checked out the Performer mailing list archives and took a look
> at some of the messages documenting the woes of my fellow
> programmers in their dealings with paging memory leaks. I tried
> the suggestions that were given in response to those messages.
>
> Things I've tried (not necessarily all at once or in this order):
>
> 1)
> Added the lines:
>
> amallopt(M_FREEHD, 1, pfGetSharedArena());
> amallopt(M_MXCHK, 10000, pfGetSharedArena());
>
> after pfInit() in main().
>
> Result: No perceptible difference in the memory leak.
>
> 2)
> Changed the line:
>
> pfMultiprocess(PFMP_APP_CULL_DRAW | PFMP_FORK_DBASE);
>
> To:
>
> pfMultiprocess(PFMP_APPCULL_DRAW | PFMP_FORK_DBASE);
>
> after pfInit() in main().
>
> Result: Seems to cut down initial application size by a few 100k
> but no perceptible difference in the memory leak.
>
> Note: Also tried PFMP_APPCULLDRAW for the heck of it. No Help.
>
> While we're on the topic, can anyone document the differences
> between these flags?
>
> 3)
> Converted some of the tiles to Performer binary ".pfb" format
> and added the line:
>
> pfdConverterMode(".pfb", PFPFB_SHARE_GS_OBJECTS, PF_OFF);
>
> after establishing shared memory in main().
>
> Result: The memory leak is the same or possibly worse.
>
> 4)
> Added:
>
> pfuClearTextureMemory();
>
> to the draw process (based on a keypress).
>
> Result: An impressive way to quickly add 10 or 20 Meg to the
> size of the application.
>
> Is there anyone out there who has had similar problems and
> managed to solve it? Anyone still living with this problem?
> ANY ideas will be greatly appreciated.
>
> -Mason
> mason++at++praxis.jsc.nasa.gov
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
-- Mark C LewisSoftware Development Manager Equipe Electronics Ltd.
"Visualising Your Imagination"
Phone +44 (0) 1903 216 622 FAX +44 (0) 1903 216 633
mailto:markl++at++equipe.ltd.uk http://www.equipe.ltd.uk
13 Liverpool Gardens Worthing, W. Sussex BN11 1RY ENGLAND
This archive was generated by hypermail 2.0b2 on Mon Apr 12 1999 - 23:58:49 PDT