[osg-users] Crash on exit (graphics thread removing camera)

[Robert Osfield]

Hi Jannik,

On 15 August 2016 at 15:03, Jannik Heller <scrawl at baseoftrash.de> wrote:
> Given that there is no documentation suggesting that removing RTT camera's is unsafe - I just assumed it was a bug :)

You can't document a issue if you haven't conceived of the specific
usage case that it's associated with :-)

What you are doing is very narrow type of usage.

> As a workaround I believe that removing the Camera's children before removing the camera should fix the crash. That means releaseGLObjects() won't be called on the Camera's subgraph on destruction but to be honest that feature seems broken to me anyway:
>
> What the intent probably was:
> - release any GL resources that are only used by this Camera
>
> What the code actually does:
> - release any GL resources of a Node only used by this Camera *and* all its child-nodes (which may be shared resources still in use by other Cameras).
>
> What are your thoughts on removing the releaseGLObjects() stuff from GraphicsContext::removeCamera - it is not working as intended, and removing it would fix the race condition as a side effect :)

Adding and removing nodes from the scene graph while it's being
co-concurrently rendered is a tough ask. There are very specific
mechanisms in place to help make it possible - i.e. PagedLOD.

The releaseGLObjects() and removeCamera() are there to make sure
resources are correctly cleaned up.  If you really try you can break
it, like hiding resources from that active parts of the viewer/scene
graph that are their to clean up things.

The key issue you are trying to push the OSG in ways that it's not
designed to handle.  If you want to dynamically add/remove Camera's
nodes then you'll need to you'll need to halt the multi-threading of
draw while you do it.

You can say the OSG should support your particular usage case but
making this possible could well be intrusive to the rest of the OSG.
The OSG has to balance the way things are designed and implemented to
make keep the feature/complexity and performance balance justified.

For your particular usage model I think the approach is pretty easy to
implement or to workaround within the client application - switch off
threading when you do unsafe tasks, or just toggle the Camera on/off.

However, ff you can spot an easy way to fix things for your usage case
without interfering with the performance and simplicity of the current
design then propose it.

Robert.