Summary: | Editor closes with memory leak (editor doesn't go away in memory) | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Richard Kulp <richkulp> | ||||
Component: | UI | Assignee: | Dani Megert <daniel_megert> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P2 | CC: | david_williams, for.work.things, gmendel, hudsonr, srich, turnham | ||||
Version: | 2.0.2 | ||||||
Target Milestone: | 2.0.2 | ||||||
Hardware: | PC | ||||||
OS: | Windows 2000 | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Richard Kulp
2002-11-04 19:05:51 EST
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. 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). |