Re: database paging memory leak

New Message Reply Date view Thread view Subject view Author view

Andreas.Ekstrand++at++saab.se
Fri, 20 Nov 1998 12:47:35 +0100


Hi Mark!

I'm hardly an expert in this area, but I have used the method myself and
experienced similar problems. I tried to page in patches of an ASD terrain
in the DBASE process by using exactly the same method as you are. My program
crashed when I used pfAsyncDelete(). After some support from SGI I succeeded
by using the following multiprocess mode:

pfMultiprocess(PFMP_APPCULL_DRAW | PFMP_FORK_DBASE | PFMP_FORK_COMPUTE)

The Compute process is used by the ASD evaluation, and can be excluded in
your case. I'm sure you already have forked the DBASE, but the trick is to
avoid forking the CULL process. Of course, this shouldn't be necessary. It's
probably a bug, but this solves the problem temporarily. Maybe this is the
source of your problem too, try it out.

Best wishes,
Andreas Ekstrand

> From: "Wear, Mark" <mark.wear++at++lmco.com>
> Date: Thu, 19 Nov 1998 10:15:01 -0700
> Subject: database paging memory leak
>
> Hello,
>
> I am using the performer DBASE process to page-in manageable chunks of
> extremely large (country size) databases. During each build, I construct the
> needed piece of scene graph in the asynchronous DBASE process within a
> pfBuffer. After construction of my new scene, I register commands to swap
> the old group (the group currently being drawn) with the new group using
> pfBufferRemoveChild and pfBufferAddChild. After pfBufferRemoveChild, I then
> request the asynchronous deletion of the old scene graph group node using
> pfAsyncDelete(). I then merge the pfBuffer. I directly modeled this method
> after an example given in the Iris Performer Student Handbook.
>
> I am experiencing a memory leak which appears to be proportional to the
> number of polygons created during a build. I have tracked this leak to the
> deletion of the old portion of scene graph. I believe this to be the case
> because if I build my new scene as usual, but never swap the new and old
> groups, and thus never call pfAsyncDelete(), the memory leak disappears.
>
> Is the memory associated with a pfBuffer freed appropriately after a merge?
> Could the request for asynchronous deletion of the old group be getting lost
> on occasion? Could my problem be caused by fragmentation of the shared
> memory arena? Is there a better way to accomplish the paging of a large
> database?
>
> Any ideas or suggestions?
>
> Thanks,
> Mark
> Mark E. Wear
> Electronic Systems Engineer
> Lockheed Martin Vought Systems
> mark.wear++at++lmco.com
> (972) 603-2758

-- 
--------------------------------------------------------------
Andreas Ekstrand, FGA-EXE   | E-mail: Andreas.Ekstrand++at++saab.se
Saab AB - Simulation Center | Phone:  +46 (0)13 - 184042
S-581 88 Linkoping          |
Sweden                      |
--------------------------------------------------------------

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Fri Nov 20 1998 - 03:47:49 PST

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