Community
Participate
Working Groups
Build 200210091450 There is a problem with the text hover which causes the editor to stay in memory after it has been closed. This keeps everything in memory; the action contributor, the SWT widgets, the EditorSite, the EditorActionBars (when this was the last editor of that type) and so on. The way to reproduce is to bring up a java editor, move the mouse over the editor and let it sit long enough for a hover to be initiated. Then close the editor by using ctrl+F4, or quickly move to the "X" in the title bar to close it. What happens is that the text hover manager doesn't remove itself from the Shell (to which it added its mouse listener as widgetDisposed listener). If you move the mouse off of the editor completely and then do ctrl+F4, mouseExit is entered, which then proceeds to remove itself as a listener on the shell before the editor is closed. And in that case, the editor is GC'd. Here is the chain of objects that cause it stay in memory (retrieved thru JProbe (TM)). - CompilationUnitEditor is referenced by CompilationUnitEditor$AdaptedSourceViewer.this$0 - CompilationUnitEditor$AdaptedSourceViewer is referenced by TextViewerHoverManager.fTextViewer - TextViewerHoverManager is referenced by AbstractHoverInformationControlManager$MouseTracker.this$0 - AbstractHoverInformationControlManager$MouseTracker is referenced by TypedListener.eventListener The TypedListener was added as a shell listener against the Shell of the workspace by AbstractHoverInformationControlManager$MouseTracker.mouseHover(...) This causes a lot of memory to not be returned, especially for our Visual Editor for Java because we have much more in memory than the straight Java Editor. There may be other things being hold in memory, but this appears to be what is holding the CompilationUnitEditor in memory. Thanks, Rich Kulp
Decreasing severitiy to 'major' until explanation of blocking behavior comes in. Increasing prio to 2. Possible cause might be the listener we added to workaround an SWT problem. This workaround will be gone with todays integration build.
Daniel, do you mean a 2.02 integration build?
No I meant "Priority" with prio - forgot to change the value. Correction of previous statement: I only looked at build ID and implied 2.1 build. The described possible cause would only apply for 2.1 builds hence it must be another problem.
Just out of curoiusity, what were you working around in SWT? Was it regarding inconsistent implementation of Control.setMouseCapture() on Motif and Windows? We had to implement a timer-based workaround for this.
Randy, we are adding hovering based on pressed keyboard modifiers. SWT failed to set the stateMask for hover events. This is now fixed. Our workaround was added in the 2.1 stream and is already gone in HEAD and with todays 2.1 I-build.
Is there any work around (or patch?) for version 2.02? This appears to effect any editor that uses TextViewerHoverManager, so can be substantial.
Today I can't reproduce when closing using the "X", but I can consistently cause it to fail when I hover over the editor and use ctrl+F4. I did some debugging and the problem is in AbstractHoverInformationControlManager.setEnabled(boolean). The problem is that in the case of hovering, the manager is already disabled, so it checks and sees that it didn't change state (during dispose a setEnabled(false) is sent), i.e. it was false and went to false, so it didn't bother calling stop on the mouse tracker. In the other cases the manager was enabled so it went from true->false and so it called stop.
Since the bug is not yet analyzed I can't say if there's a workaround. Patches are normally grouped by a release (e.g. 2.0.1). I don't know the exact schedule for 2.0.2. Kevin Haaland manages the releases. Besides the leak: do you see an exception or error dialog? I could not reproduce it on my machine yet. Do I have to do something fast? Do I need to close the editor before the hover shows up?
I was able to simply do it by moving the mouse over the editor, wait a second and then hit ctrl+F4. The editor will close, but it will not go out of memory.
Can I see the problem without using JProbe or OptimizeIt i.e. is there an immediate problem resulting from this (e.g. dialog or log message)?
There is nothing visible. It is a memory leak. Disposed editors and all they reference don't go away. They accumulate during the session using up memory that is never reclaimed. You can debug into it as I shown in comment #8. At that point you can walk up the parent chain of the controls to the shell and inspect to see that the MouseTracker is still a listener on the shell, and that when stepping through the setEnabled it doesn't call the stop so it leaves with the MouseTracker still attached. The MouseTracker references eventually reach the CompilationUnitEditor itself, which drags everything else in.
We did not yet investigate. With my queations I tried to find out why it was marked as blocker. Blocker means you can no longer work. I agree that leaking editors is a major or even critical error.
The main reason I made it blocking is because 2.0.2 and WSAD are just about ready to go out the door and you and we don't have much time. It would be blocking in our case if we have to wait for 2.0.3 (if there is one, I don't know if you have one planned) and I don't know if WSAD would be able to pick up 2.0.3 in a fix pack, which it may not. Those decisions either haven't been made yet or haven't been communicated to me yet. It would be far too long for us to wait for 2.1. The leakage is fairly large. I'm sorry I didn't catch this awhile back. In that case I would of marked it critical instead. I didn't really notice it before because in testing and development we are typically only up for short periods of time and we have a lot of memory on our systems. On a memory constrained system this would show up a lot sooner. You can change the priority if you wish, but I think it is a mustfix for 2.0.2. Thanks, Rich
Rich, I sent a note to Kevin who manages 2.0.2. Do you know if this leak was actually introduced with 2.0.2 or might it be in there for a while?
Nope, I don't know when it was introduced. Probably before 2.0.2 I would imagine. Maybe even all of the way back to 2.0.0. The leak is a lot smaller for just the java editor, so it doesn't show up as fast. It was different for our visual editor because we have a much larger footprint per editor.
I got the OK from Kevin Haaland that we can add the fix to 2.0.2.
We found and attached a patch for the problem in the described scenario with the text hover.
Reopen bug - no commit rights. Sending patch to Claude to release.
Created attachment 2333 [details] Patch to be applied on AbstractHoverInformationControlManager
Patch has been released to 2.0.2 stream. Keeping PR open until it's in the next 2.0.2 build.
released patch to R2_0_1 and HEAD.
in stream, but not in build yet.
setting target milestone to 2.0.2
I just tested the patch on my machine. It works very well! Thanks, Rich Kulp
The fix has been included in yesterdays 2.0.2 build (I20021107).
