Community
Participate
Working Groups
While testing my implementation of bug #93955, I noticed I was leaking a document (and prototyped DocumentUndoManager) on every open editor. OptimizeIt shows it as stemming from JavaTextTools. There is one of these references leaked for each open/closed editors. This can also be verified by checking for instances of PartiallySynchronizedDocument in the JavaLeakTest. Here is the OptimizeIt reference trace after opening and closing an editor. org.eclipse.jface.text.DocumentUndoManager org.eclipse.jface.text.DocumentUndoManager@10f0fbd fUndoManager of org.eclipse.jdt.internal.ui.javaeditor.PartiallySynchronizedDocument org.eclipse.jdt.internal.ui.javaeditor.PartiallySynchronizedDocument... fDocument of org.eclipse.jdt.internal.ui.text.BufferedDocumentScanner org.eclipse.jdt.internal.ui.text.BufferedDocumentScanner@362fee fScanner of org.eclipse.jdt.internal.ui.text.FastJavaPartitionScanner org.eclipse.jdt.internal.ui.text.FastJavaPartitionScanner@eba36c fPartitionScanner of org.eclipse.jdt.ui.text.JavaTextTools org.eclipse.jdt.ui.text.JavaTextTools@13b8e0f fJavaTextTools of org.eclipse.jdt.internal.ui.JavaPlugin org.eclipse.jdt.ui Static variable of class org.eclipse.jdt.internal.ui.JavaPlugin plugin of org.eclipse.core.internal.compatibility.PluginActivator org.eclipse.core.internal.compatibility.PluginActivator@1e0467a this$0 of org.eclipse.jdt.internal.ui.JavaPlugin$2 org.eclipse.jdt.internal.ui.JavaPlugin$2@1116a10
Running I20050823-0800 with HEAD versions of org.eclipse.text, org.eclipse.jface.text,org.eclipse.workbench.texteditor, org.eclipse.ui.workbench, org.eclipse.ui.ide (and others). I can try this from a stock build if you cannot reproduce.
Susan, personally I'd say you're reporting bug 61432 which is not a leak ;-) Having said that there might be in fact a leak starting with this Wednesday's N-build since one of the leak tests constantly fails. I'll look into it.
I would agree that this is the same bug if there were only one document reference kept. If that were true, I could change my leak tests to count references, run the tests, and then assert that the count was where it started. However I observed that there was a document reference left for every single editor opened and closed. For example, during the profiling session, I opened 6 java editors and closed them. I had 6 instances of PartiallySynchronizedDocument and each one had the same reference trace.
I tested did the following using I20050830-0800: - opened several editors and close them each by each - opened several editors and closed them using Close All ==> only one document remains (which as of bug 61432). Note that whatever tool you use you might have to run the garbage collector several times to allow disposal of the instances. However there's a bad leak in org.eclipse.ui.workbench (HEAD and recent N-builds) which I currently try to narrow down a bit closer than just the project.
I ran GC enough to see many instances go away, but always had the last remaining N instances around. I was using optimizeit, which seems to GC before showing a ref trace, because you see many instances disappear then, too. But the ref trace being the same does support your theory. I will double check my modified leak tests and report back if there is still a discrepancy. Thanks.
FYI: the current leak is caused by bug 108709.
