#305 Memory leaks caused by particle system

[Anonymous]

Originally created by: bre... (code.google.com)@gmail.com

(from the devel mailing list)
What steps will reproduce the problem?
1. I started an MP session at KSFO (lots of MP
aircraft), then warped to the middle of nowhere (no MP aircraft).
2. After about 30min I dumped the scene graph. Surprisingly, loads of
osg::particles were still *in* the scene graph, referring to aircraft
specific smoke and contrail textures.

What is the expected output? What do you see instead?
I would have expected them to be
dropped from the scene graph after some time - or when we move to a
very distant position.

What version (or GIT date / Hudson build number)?
GIT as of April 16th, 2011

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

On 16.04.2011 15:50, Anders Gidenstam wrote:
IIRC each particle system is attached to the scene graph in (at least) two places: at the emitter's location in the graph and in a global vector of particle system updaters. IIRC they are never removed from the global list of updaters (a bug - but a hard one to fix due to concurrency issues). Tim knows more about this.

My failed attempt to unlink the particle systems might provide some insight into that issue. The attempt is broken because the
methods calls
            if (!Particles::getCommonRoot()->removeChild(item)) {
or
            if (!Particles::getCommonGeode()->removeDrawable(item)) {
can get called while another OSG thread traverses or inserts into the vector of children to the common root/geod.

Basically the ~CustomMatrixTransform() destructor is called on the wrong thread for this attempt to work. The clean up action needs either to be communicated to the right thread or synchronization added to removeChild/Drawable() method (which would be against the OSG design).

(Note: the preprocessor variable OSG_PARTICLE_FIX is unrelated to my changes.)

IIRC the current code already does the fundamentaly unsafe operation of
adding items to a STL vector (in the loader thread) while concurrent
traversals of the same vector are possible (by various parts of OSG
rendering). That is NOT SAFE but a lot less risky than deleting from an
STL vector with concurrent traversal (consider the most likely internal
representation of a STL vector to see why).

Labels: osg SimGear

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

Stalled, since we don't expect any progress here for a while - and assume the impact to be very low.

Status: Stalled

[Anonymous]

Originally posted by: bre... (code.google.com)@gmail.com

(No comment was entered for this change.)

Labels: Priority-Low

[Anonymous]

Originally posted by: zakalawe@mac.com

I encountered something similar yesterday by travelling in a straight line at full-speed in the UFO - which obviously pushed the loader code, and hence particles, much harder than a real aircraft ever could. In my case it memory corruption / exhaustion, but  in general the code probably needs to be audited. (Mathias indicated serious problems with it too)

[Anonymous]

Originally posted by: cumuluni... (code.google.com)@gmail.com

assuming expired.

Status: Expired