DrJava DefinitionsPaneMemoryLeakTest fails on Mac

I submitted a bugfix for a problem with the debug panel when no
debugger is available
.

I noticed that on the Mac, the DefinitionsPaneMemoryLeakTest now
fails:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
   [junit] DefinitionsPaneMemoryLeakTest                26.92 sec
   [junit] Testsuite: edu.rice.cs.drjava.ui.DefinitionsPaneMemoryLeakTest
   [junit] Tests run: 1, Failures: 1, Errors: 0
   [junit] ------------- Standard Error -----------------
   [junit] Skipped analysing class java.security.ProtectionDomain
because of java.lang.AssertionError
   [junit] ------------- ---------------- ---------------
   [junit] Testcase:
testDocumentPaneMemoryLeak(edu.rice.cs.drjava.ui.DefinitionsPaneMemoryLeakTest):        FAILED
   [junit] Document 0 leaked:
   [junit] private static sun.awt.AppContext
sun.awt.AppContext.mainAppContext->
   [junit] sun.awt.AppContext@4998a455-table->
   [junit] java.util.HashMap@7f1bfcfc-table->

...

   [junit] [Ljava.beans.PropertyChangeListener;@67b50846-[373]->
   [junit] javax.swing.JViewport$1@7ceade87-this$0->
   [junit] javax.swing.JViewport@48be3a5e-component->
   [junit] java.util.ArrayList@6b333f77-elementData->
   [junit] [Ljava.lang.Object;@559b52d3-[0]->
   [junit] edu.rice.cs.drjava.ui.DefinitionsPane@2a38d0a8-_doc->
   [junit] edu.rice.cs.drjava.model.DefaultGlobalModel$ConcreteOpenDefDoc@557e5cbd
   [junit]     at
org.netbeans.test.MemoryTestUtils.assertGC(MemoryTestUtils.java:137)

It passes on Windows, and I haven’t tried it on Linux. I rolled
back as far as revision 5266, which was from June 3, 2010, and it was
still failing on the Mac. I have a feeling that something must have
changed in Mac OS (Lion) or the Java version I have running
(1.6.0_29). I know I’ve successfully run the unit tests many times
since then on the Mac, even on my MacBook Pro. I even think I have run
them successfully on Mac OS Lion.

It would be great if I could still run the unit tests on an older Mac, with an older Mac OS. I’ll dig into this, but it may take some time.

Share

About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in DrJava. Bookmark the permalink.

5 Responses to DrJava DefinitionsPaneMemoryLeakTest fails on Mac

  1. demotivator says:

    I ran into a memory leak problem after that Mac update as well. On 10.6 the Update 6 for Java release on 11/8/2011 updates to 1.6.0_29. I have confirmed that it causes massive memory leaks in my application, and I have yet to find a solution other than reverting back to the prior version of Java. I’m only able to do that because I saved a copy of the previous Java version on my Mac before applying the upgrade, Apple doesn’t seem to offer any downgrade options.

    I’ve confirmed that 1.6.0_29 on Windows does not have the problem, only Mac. Fortunately for me I have very few users of my application on Mac, and have been able to help them manually roll back their Java version until we can find a proper solution. I’ve chased down and fixed memory leaks before, but I can’t find anything that I’m doing to cause this one. Seems to be rooted in a pretty similar path as your post shows, AppContext -> property change listener -> JViewport.

    If I find a solution, I’ll try to post it back on your blog in case others are looking for it.

    Glad to see your post, I was starting to wonder if I was the only one who’d encountered this issue!

  2. demotivator says:

    I found the source of the problem. It appears to be caused by the change made for Radar bug #10010502. The following code was new in this release in the JViewport.java:

    final Toolkit toolkit = Toolkit.getDefaultToolkit();
    if (toolkit instanceof apple.awt.CToolkit) {
    final boolean isRunningInHiDPI = ((apple.awt.CToolkit)toolkit).runningInHiDPI();
    if (isRunningInHiDPI) setScrollMode(SIMPLE_SCROLL_MODE);
    toolkit.addPropertyChangeListener(“apple.awt.contentScaleFactor”, new PropertyChangeListener() {
    private int oldScrollMode = isRunningInHiDPI ? SIMPLE_SCROLL_MODE : BLIT_SCROLL_MODE;

    
    
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
                @Override
                public void propertyChange(PropertyChangeEvent evt) {
                    if ("apple.awt.contentScaleFactor".equals(evt.getPropertyName())) {
                        final int currentScrollMode = getScrollMode();
                        setScrollMode(((apple.awt.CToolkit)toolkit).runningInHiDPI() ? SIMPLE_SCROLL_MODE : oldScrollMode);
                        oldScrollMode = currentScrollMode;
                    }
                }
            });
        }

    There was no attempt to remove / cleanup the new property listener that is getting added, and it is causing the JVM to not garbage collect the objects associate with the JViewport being created. I found if I manually add the following code to my application, the memory leak is resolved, but it probably breaks their scrolling change since I’m just removing all of these listeners, even ones that are still in scope:

    final Toolkit toolkit = Toolkit.getDefaultToolkit();
    if (toolkit instanceof apple.awt.CToolkit) {
    PropertyChangeListener[] leak = toolkit.getPropertyChangeListeners(“apple.awt.contentScaleFactor”);
    for(int i=0; i<leak.length; i++){
    toolkit.removePropertyChangeListener("apple.awt.contentScaleFactor",leak[i]);
    }
    }

    I filed a Radar bug #10473138 for this, hopefully Apple will fix it, but at least I have a workaround now.

  3. Mathias says:

    Hi demotivator,

    Thanks for your comments to let me know that I’m not the only one experiencing this, and for your hard work in finding a work-around. I’ll see if this can help us too.

  4. chubbard says:

    So is there no way we can roll back to the update to Java 1.6.0_29 to a previous version of Java on the Mac? This update is killing IntelliJ and spiking its memory out almost making it unusable. It was so stable prior to this upgrade. Probably the best version yet, but damn this bug is screwing my productivity.

  5. Mathias says:

    Unfortunately I’m not aware of a way to roll back, Charlie. If I find something, I’ll let you know.

Leave a Reply