next »

[boogie]

Feel free to move this thread to bug forum.

While manipulating the scenegraph, the exception below will occur.

It seems the methods addChild() or removeChild() of grouping classes like GroupNode, TransformGroup aren't thread-safe. In some cases adding and removing objects with running rendering loop will cause null pointer exceptions to be thrown. In this case the application will quit suddenly, without beeing able to handle these exceptions. The bug is severe.

The effect is reproducible very well with manipulation of many objects at the same time. However it might be hard to find this situation: a child of a group is to be rendered at the moment where its object reference becomes a null reference due to removal at the same time.

Note: as the exception shown lists line numbers from the latest binary distribution, the bug is also reproducible with the source distribution from SVN.

Code:

java.lang.NullPointerException
        at org.xith3d.render.preprocessing.FrustumCuller.cullNodeAtoms(FrustumCuller.java:222)
        at org.xith3d.render.preprocessing.FrustumCuller.cullGroupAtoms(FrustumCuller.java:140)
        at org.xith3d.render.preprocessing.FrustumCuller.cullNodeAtoms(FrustumCuller.java:320)
        at org.xith3d.render.preprocessing.FrustumCuller.cullGroupAtoms(FrustumCuller.java:140)
        at org.xith3d.render.preprocessing.FrustumCuller.cullNodeAtoms(FrustumCuller.java:320)
        at org.xith3d.render.preprocessing.FrustumCuller.cullGroupAtoms(FrustumCuller.java:140)
        at org.xith3d.render.preprocessing.FrustumCuller.cullNodeAtoms(FrustumCuller.java:320)
        at org.xith3d.render.preprocessing.FrustumCuller.cullGroupAtoms(FrustumCuller.java:140)
        at org.xith3d.render.preprocessing.FrustumCuller.cullNodeAtoms(FrustumCuller.java:320)
        at org.xith3d.render.preprocessing.FrustumCuller.cullAtoms(FrustumCuller.java:348)
        at org.xith3d.render.preprocessing.FrustumCuller.cullAtoms_normal(FrustumCuller.java:390)
        at org.xith3d.render.preprocessing.FrustumCuller.cullAtoms(FrustumCuller.java:598)
        at org.xith3d.render.DefaultRenderer.renderOnceInternal(DefaultRenderer.java:636)
        at org.xith3d.render.DefaultRenderer.renderOnce(DefaultRenderer.java:819)
        at org.xith3d.base.Xith3DEnvironment.render(Xith3DEnvironment.java:501)
        at org.xith3d.loop.RenderLoop.renderNextFrame(RenderLoop.java:619)
        at org.xith3d.loop.RenderLoop.loopIteration(RenderLoop.java:642)
        at org.xith3d.loop.RenderLoop.update(RenderLoop.java:698)
        at org.xith3d.loop.UpdatingThread.nextIteration(UpdatingThread.java:487)
        at org.xith3d.loop.RenderLoop.nextIteration(RenderLoop.java:709)
        at org.xith3d.loop.RenderLoop.loop(RenderLoop.java:762)
        at org.xith3d.loop.UpdatingThread.run(UpdatingThread.java:540)
        at org.xith3d.loop.RenderLoop.run(RenderLoop.java:785)
        at java.lang.Thread.run(Thread.java:619)

[Oliver]

Maybe I got you wrong, but as far as I understood the system, the scenegraph must not be accessed (changed) from outside the renderloop (which is very common for 3D/game engines as well as many plugIn systems).

e.g. see method prepareNextFrame( long gameTime, long frameTime, UpdatingThread.TimingMode timingMode)
in class RenderLoop

That means if you add and detach nodes from within the appropriate callback, there should be no problem. At least it works (still) in the applications I wrote.

Cheers,
Oliver

[Marvin Fröhlich]

That's correct. Xith3D is NOT thread safe. Though you can do it the way outlined above (overriding certain methods of RenderLoop) or you can use ScheduledOperations or Intervals or Updatables. Have a look at the XIN examples in xith-tk.

Marvin