Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.3.2
    • Fix Version/s: not determined
    • Component/s: j3d-core
    • Labels:
      None
    • Environment:

      Operating System: Windows XP
      Platform: PC

    • Issuezilla Id:
      134
    • Status Whiteboard:
      Hide

      placeholder

      Show
      placeholder

      Description

      Hi,

      here's my Canvas3D stress test for the suspect memory leak (et similia) I
      outlined on the java3d lists.
      The main class is in Canvas3DStressTest.java

      Just give it a run and wait for some seconds (let's say 60-120).
      It fails with my two machines: one with a matrox parhelia and one with a NVidia
      FX 5700 (both with the latest drivers/ j3d).

        Activity

        Hide
        mikofclassx added a comment -

        Created an attachment (id=85)
        source code

        Show
        mikofclassx added a comment - Created an attachment (id=85) source code
        Hide
        kcr added a comment -

        Looks like there is a missing class:

        .\it\classx\util\java3d\PictureGrabberCanvas3D.java:3: cannot find symbol
        symbol : class Util
        location: package it.classx.util
        import it.classx.util.Util;
        ^
        .\it\classx\util\java3d\PictureGrabberCanvas3D.java:72: package
        it.classx.globals.Globals does not exist

        Util.paintCheckerboard(w,h,gc,8,8,it.classx.globals.Globals.baselight0_color.darker(),it.classx.globals.Globals.baselight1_color);
        ^
        .\it\classx\util\java3d\PictureGrabberCanvas3D.java:72: package
        it.classx.globals does not exist

        Util.paintCheckerboard(w,h,gc,8,8,it.classx.globals.Globals.baselight0_color.darker(),it.classx.globals.Globals.baselight1_color);

        ^
        .\it\classx\util\java3d\PictureGrabberCanvas3D.java:72: cannot find symbol
        symbol : variable Util
        location: class it.classx.util.java3d.PictureGrabberCanvas3D

        Util.paintCheckerboard(w,h,gc,8,8,it.classx.globals.Globals.baselight0_color.darker(),it.classx.globals.Globals.baselight1_color);
        ^
        4 errors

        Show
        kcr added a comment - Looks like there is a missing class: .\it\classx\util\java3d\PictureGrabberCanvas3D.java:3: cannot find symbol symbol : class Util location: package it.classx.util import it.classx.util.Util; ^ .\it\classx\util\java3d\PictureGrabberCanvas3D.java:72: package it.classx.globals.Globals does not exist Util.paintCheckerboard(w,h,gc,8,8,it.classx.globals.Globals.baselight0_color.darker(),it.classx.globals.Globals.baselight1_color); ^ .\it\classx\util\java3d\PictureGrabberCanvas3D.java:72: package it.classx.globals does not exist Util.paintCheckerboard(w,h,gc,8,8,it.classx.globals.Globals.baselight0_color.darker(),it.classx.globals.Globals.baselight1_color); ^ .\it\classx\util\java3d\PictureGrabberCanvas3D.java:72: cannot find symbol symbol : variable Util location: class it.classx.util.java3d.PictureGrabberCanvas3D Util.paintCheckerboard(w,h,gc,8,8,it.classx.globals.Globals.baselight0_color.darker(),it.classx.globals.Globals.baselight1_color); ^ 4 errors
        Hide
        mikofclassx added a comment -

        Created an attachment (id=86)
        source code - fixed compilation errors

        Show
        mikofclassx added a comment - Created an attachment (id=86) source code - fixed compilation errors
        Hide
        mikofclassx added a comment -

        Compilation errors fixed in the attatchment #86. Sorry.

        Show
        mikofclassx added a comment - Compilation errors fixed in the attatchment #86. Sorry.
        Hide
        kcr added a comment -

        It looks like your program recursively calls setOffScreenBuffer from its
        overridden Canvas.setSize method, which is leading to a deadlock.

        at java.lang.Thread.sleep(Native Method)
        at javax.media.j3d.MasterControl.threadYield(MasterControl.java:3611)
        at javax.media.j3d.Canvas3D.sendCreateOffScreenBuffer(Canvas3D.java:4063)
        at javax.media.j3d.Canvas3D.setOffScreenBuffer(Canvas3D.java:1833)
        at PictureGrabberCanvas3D.setSize(PictureGrabberCanvas3D.java:112)
        at java.awt.Component.resize(Component.java:1804)
        at java.awt.Component.setSize(Component.java:1795)
        at javax.media.j3d.Canvas3D.setOffScreenBuffer(Canvas3D.java:1830)
        at Canvas3DStressTest$BuilderThread$1.run(Canvas3DStressTest.java:94)
        at java.lang.Thread.run(Thread.java:595)

        I don't know whether this is causing the other problem you are seeing (probably
        not), but it is preventing us from making progress.

        I'm a little puzzled as to why the offscreen "Canvas" is being resized from
        AWT--it shouldn't be added to any Container (if it is, then that's a bug), so I
        don't know why AWT would call setSize on the Component.

        In any case, please eliminate the recursive call, and then post a new version of
        your test program. Thanks.

        – Kevin

        Show
        kcr added a comment - It looks like your program recursively calls setOffScreenBuffer from its overridden Canvas.setSize method, which is leading to a deadlock. at java.lang.Thread.sleep(Native Method) at javax.media.j3d.MasterControl.threadYield(MasterControl.java:3611) at javax.media.j3d.Canvas3D.sendCreateOffScreenBuffer(Canvas3D.java:4063) at javax.media.j3d.Canvas3D.setOffScreenBuffer(Canvas3D.java:1833) at PictureGrabberCanvas3D.setSize(PictureGrabberCanvas3D.java:112) at java.awt.Component.resize(Component.java:1804) at java.awt.Component.setSize(Component.java:1795) at javax.media.j3d.Canvas3D.setOffScreenBuffer(Canvas3D.java:1830) at Canvas3DStressTest$BuilderThread$1.run(Canvas3DStressTest.java:94) at java.lang.Thread.run(Thread.java:595) I don't know whether this is causing the other problem you are seeing (probably not), but it is preventing us from making progress. I'm a little puzzled as to why the offscreen "Canvas" is being resized from AWT--it shouldn't be added to any Container (if it is, then that's a bug), so I don't know why AWT would call setSize on the Component. In any case, please eliminate the recursive call, and then post a new version of your test program. Thanks. – Kevin
        Hide
        mikofclassx added a comment -

        Created an attachment (id=87)
        source code - no more setSize()

        Show
        mikofclassx added a comment - Created an attachment (id=87) source code - no more setSize()
        Hide
        kcr added a comment -

        As indicated in the description, Java 3D is leaking resources; in this case the
        native Pbuffers are never being destroyed. The underlying problem is that the
        renderer is no longer runnable when the application calls
        Canvas3D.setOffScreenBuffer(null). Once the viewing platform has been removed
        from the scene graph, which happens as a result of removeAllLocales, the
        renderer is stopped, so calls to setOffScreenBuffer can't be processed. This
        limitation isn't likely be addressed any time soon, so the application needs to
        ensure that cleanup is done in the proper order, which means that the Java 3D
        javadocs need to be updated to indicate what the proper order is.

        We have checked in a fix for users of SimpleUniverse.cleanup(). The cleanup
        method now calls Canvas3D.setOffScreenBuffer(null) for each off-screen canvas
        before removing the canvas from the view, and before removing all locales from
        the universe.

        Users who do not call SimpleUniverse.cleanup() will need to follow the same
        sequence of operations to cleanup their resources. That sequence is:

        1. Set the off-screen buffer to null for each off-screen Canvas3D

        2. Remove all Canvas3Ds (both on-screen and off-screen) from the View

        3. Attach a null ViewPlatform to the View

        4. Remove all Locales from the VirtualUniverse

        Note: I'm leaving this bug open as a placeholder (and lowering the priority to
        P5), since we still need to update the docs with this information. I'll file a
        separate issue on that.

        Show
        kcr added a comment - As indicated in the description, Java 3D is leaking resources; in this case the native Pbuffers are never being destroyed. The underlying problem is that the renderer is no longer runnable when the application calls Canvas3D.setOffScreenBuffer(null). Once the viewing platform has been removed from the scene graph, which happens as a result of removeAllLocales, the renderer is stopped, so calls to setOffScreenBuffer can't be processed. This limitation isn't likely be addressed any time soon, so the application needs to ensure that cleanup is done in the proper order, which means that the Java 3D javadocs need to be updated to indicate what the proper order is. We have checked in a fix for users of SimpleUniverse.cleanup(). The cleanup method now calls Canvas3D.setOffScreenBuffer(null) for each off-screen canvas before removing the canvas from the view, and before removing all locales from the universe. Users who do not call SimpleUniverse.cleanup() will need to follow the same sequence of operations to cleanup their resources. That sequence is: 1. Set the off-screen buffer to null for each off-screen Canvas3D 2. Remove all Canvas3Ds (both on-screen and off-screen) from the View 3. Attach a null ViewPlatform to the View 4. Remove all Locales from the VirtualUniverse Note: I'm leaving this bug open as a placeholder (and lowering the priority to P5), since we still need to update the docs with this information. I'll file a separate issue on that.
        Hide
        kcr added a comment -

        Updated status

        Show
        kcr added a comment - Updated status
        Hide
        kcr added a comment -

        As indicated above, the underlying problem is addressed by a change to the
        SimpleUniverse.cleanup() method, which has been done. We have documented the
        steps needed for applications that do not use SimpleUniverse in the Application
        Knowledge Base section of the Java 3D Wiki. The URL for this is:

        http://wiki.java.net/bin/view/Javadesktop/Java3DApplicationDevelopment#UniverseCleanup

        I am closing this bug as resolved/fixed.

        Show
        kcr added a comment - As indicated above, the underlying problem is addressed by a change to the SimpleUniverse.cleanup() method, which has been done. We have documented the steps needed for applications that do not use SimpleUniverse in the Application Knowledge Base section of the Java 3D Wiki. The URL for this is: http://wiki.java.net/bin/view/Javadesktop/Java3DApplicationDevelopment#UniverseCleanup I am closing this bug as resolved/fixed.

          People

          • Assignee:
            java3d-issues
            Reporter:
            mikofclassx
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: