The infamous dbase paging memory leak

New Message Reply Date view Thread view Subject view Author view

Mason D. Menninger (mason++at++praxis.jsc.nasa.gov)
Mon, 12 Apr 1999 14:26:54 -0500 (CDT)

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

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Apr 12 1999 - 12:27:20 PDT

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