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

[Robert Osfield]

Hi Jannik,

On 16 August 2016 at 17:44, Jannik Heller <scrawl at baseoftrash.de> wrote:
> I don't need to remove it during runtime, I remove it on exit. Obviously it's a good idea to remove stuff on exit to avoid memory leaks. You *could* just leave your scene as it is and let OSG clean it up when the viewer exits - but I like to follow the principle of: whoever creates an object should be responsible for removing it ;)

The OSG uses smart pointers within the viewer and scene graph so there
is no need to manually track memory management, it'll clean things up
for you.


>> Also something that seems a bit odd - why an in scene graph Camera has
>> a GraphicsContext assigned to it. Normally in scene graph Camera
>> don't have an GraphicsContext, instead inherit the GraphicsContext
>> from the viewer's Camera. If Camera needs it's own
>> GraphicsContext/Window then would typically best done by having a
>> Camera at the Viewer level rather than in the scene graph. Again I
>> don't know why you've gone for the approach you have, all I can say it
>> might not be appropriate.
>
> I assigned the same GraphicsContext that I'm using for the window. I thought that would be equivalent to just leaving the GraphicsContext as NULL and letting it inherit, I didn't realize there might be side effects to explicitely setting the GraphicsContext.

The side effects are only appearing because you are mixing in lots of
other things as well - i.e. threading, removing objects before the
drawing thread has completed, sharing subgraphs.

As a general design you should avoid assigning the GraphicsContext for
in scene graph Camera's as it limits how reusable the scene graph is,
you are looking high levels parts of the application with lower levels
in the scene graph rather than leaving then loosely coupled.  Scene
graphs like the OSG are built to enable loose coupling as this
provides much greater flexibility i.e. you can alter the viewer
configuration and the scene graph independently.  A lot of work has
gone into this part of the design of the OSG, you can still break it
if you wish as the design is so flexible, mostly this is fine, but in
your case you've added extra complexity for no functionality gain and
found a way to break things that would have otherwise work perfectly
had you gone the straight fordward route.

> Thanks for this note, now I have a better understanding of what Camera::setGraphicsContext actually does :)
>
> So I guess we have at least 3 different workarounds then:
>
> - Leave the camera's GraphicsContext as NULL
> - Remove the Camera's children before removing the Camera
> - Wait for the graphics thread to finish (i.e. stop viewer threading) before removing the camera

Frankly we are talking about workarounds, we are talking about fixing
the way you are setting up your application and scene graph to keep it
nicely decoupled.  Simply don't assign the graphics context to the
Camera and don't remove elements in the scene graph that you don't
need to.  The OSG will do the right thing for you, just trust it.

Robert.