Bugzilla – Full Text Bug Listing
| Summary: | SWTError: No more handles when clicking between editor and Git Repositories view | ||
|---|---|---|---|
| Product: | [Technology] EGit | Reporter: | Marc-André Laperle <malaperle> |
| Component: | UI | Assignee: | Kevin Sawicki <kevin> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | adalbert.homa, daniel_megert, eclps.ronk, gary_mcwilliams, jakub.kopec, javabrett, lukas.olbrich, matthias.sohn, pwebster, remy.suen |
| Version: | 1.2 | ||
| Target Milestone: | 2.0-M1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Marc-André Laperle
For reference this is still happening with 1.2.0.201112101922. Just to make sure, I installed a fresh Eclipse SDK 3.7.1, created a new workspace, created a new git repo and I get the error with the same steps. I tried this with a fresh SDK 3.7.1 and today's egit nightly on Mac OS X 10.6.8 and can't reproduce this problem. I clicked many times in the editor and the repository but no SWTError shows up. History View is linked with editor and selection. For whoever can reproduce the problem, try installing and running sleak: http://www.eclipse.org/swt/tools.php It's designed to help find leaking SWT resources. PW I couldn't reproduce it on separate Vista PC and Ubuntu 11.4. I'll try on a second Windows 7 PC tomorrow. (In reply to comment #3) > For whoever can reproduce the problem, try installing and running sleak: > http://www.eclipse.org/swt/tools.php > > It's designed to help find leaking SWT resources. > > PW I didn't see anything suspicious with Sleak, it looked like there's a reasonable number of resources before and after the error. (In reply to comment #4) > I couldn't reproduce it on separate Vista PC and Ubuntu 11.4. I'll try on a > second Windows 7 PC tomorrow. I can't reproduce it on a second Windows 7 PC. This is very strange since I can reproduce it 100% with fresh Eclipse SDK + Egit installs on the original PC, there must be something external that affects this. I will lower the importance for now since this looks isolated. I can't reproduce this problem using a fresh 3.7.1 SDK windows 64 bit with EGit 1.2.0.201112121913 and JGit 1.2.0.201112121111 on Windows 7 Enterprise. I did a binary search in the commits and have determined that commit 11dce4a2ad81830fdb356a774223b21dc05cf8f0 (Add action links when Git Repositories view is empty) has introduced the problem. I added a call to GetLastError just after it fails to get an handle (CreateWindowEx) and it returns 0, which means no error in win32, that's suspicious. I changed RepositoriesView.createPartControl to call super.createPartControl(aParent); instead of super.createPartControl(displayArea); and then I don't get the error (but of course the view looks wrong). It looks like there might be something going wrong in the parent/child relationship. I'm still clueless as to why I can reproduce that on only one PC though. Matthias, do you see anything suspicious in that area of the code? Anyone else CC'd seeing this bug? Yes, I am also facing this bug, my config: eclipse modeling tools eclipse.buildId=M20110909-1335 Eclipse EGit 1.1.0.201109151100-r automated update does not show any available updates. sry, my fault with the wrong version, just updated to: Eclipse EGit 1.2.0.201112221803-r And the stack trace is always the same when this issues occurs? It traces back to: org.eclipse.team.internal.ui.history.GenericHistoryView.showPageRec(GenericHistoryView.java:649) My full stacktrace, just occured today with eGit 1.2. yes, it traces back to GenericHistoryView. org.eclipse.swt.SWTError: No more handles at org.eclipse.swt.SWT.error(SWT.java:4308) at org.eclipse.swt.SWT.error(SWT.java:4197) at org.eclipse.swt.SWT.error(SWT.java:4168) at org.eclipse.swt.widgets.Widget.error(Widget.java:468) at org.eclipse.swt.widgets.Control.createHandle(Control.java:704) at org.eclipse.swt.widgets.Sash.createHandle(Sash.java:119) at org.eclipse.swt.widgets.Control.createWidget(Control.java:744) at org.eclipse.swt.widgets.Control.<init>(Control.java:112) at org.eclipse.swt.widgets.Sash.<init>(Sash.java:77) at org.eclipse.swt.custom.SashForm.createSash(SashForm.java:99) at org.eclipse.swt.custom.SashFormLayout.layout(SashFormLayout.java:115) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1263) at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java:1673) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4603) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.WM_WINDOWPOSCHANGED(Control.java:5408) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4616) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.EndDeferWindowPos(Native Method) at org.eclipse.swt.widgets.Composite.resizeChildren(Composite.java:949) at org.eclipse.swt.widgets.Composite.resizeChildren(Composite.java:915) at org.eclipse.swt.widgets.Composite.setResizeChildren(Composite.java:1126) at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java:1677) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4603) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.WM_WINDOWPOSCHANGED(Control.java:5408) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4616) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.EndDeferWindowPos(Native Method) at org.eclipse.swt.widgets.Composite.resizeChildren(Composite.java:949) at org.eclipse.swt.widgets.Composite.resizeChildren(Composite.java:915) at org.eclipse.swt.widgets.Composite.setResizeChildren(Composite.java:1126) at org.eclipse.swt.widgets.Composite.WM_SIZE(Composite.java:1677) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4603) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.WM_WINDOWPOSCHANGED(Control.java:5408) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4616) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4972) at org.eclipse.swt.internal.win32.OS.SetWindowPos(Native Method) at org.eclipse.swt.widgets.Widget.SetWindowPos(Widget.java:1457) at org.eclipse.swt.widgets.Control.setBounds(Control.java:3124) at org.eclipse.swt.widgets.Composite.setBounds(Composite.java:1019) at org.eclipse.swt.widgets.Control.setBounds(Control.java:3085) at org.eclipse.swt.widgets.Control.setBounds(Control.java:3081) at org.eclipse.swt.widgets.Control.setBounds(Control.java:3148) at org.eclipse.ui.part.PageBook$PageBookLayout.layout(PageBook.java:67) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1263) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1249) at org.eclipse.swt.widgets.Composite.layout(Composite.java:664) at org.eclipse.swt.widgets.Composite.layout(Composite.java:622) at org.eclipse.ui.part.PageBook.showPage(PageBook.java:103) at org.eclipse.team.internal.ui.history.GenericHistoryView.showPageRec(GenericHistoryView.java:649) at org.eclipse.team.internal.ui.history.GenericHistoryView.showHistoryPageFor(GenericHistoryView.java:741) at org.eclipse.team.internal.ui.history.GenericHistoryView.showHistory(GenericHistoryView.java:969) at org.eclipse.team.internal.ui.history.GenericHistoryView.editorActivated(GenericHistoryView.java:892) at org.eclipse.team.internal.ui.history.GenericHistoryView$1.partActivated(GenericHistoryView.java:362) at org.eclipse.ui.internal.PartListenerList$1.run(PartListenerList.java:72) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.runtime.Platform.run(Platform.java:888) at org.eclipse.ui.internal.PartListenerList.fireEvent(PartListenerList.java:57) at org.eclipse.ui.internal.PartListenerList.firePartActivated(PartListenerList.java:70) at org.eclipse.ui.internal.PartService.firePartActivated(PartService.java:187) at org.eclipse.ui.internal.PartService.setActivePart(PartService.java:306) at org.eclipse.ui.internal.WorkbenchPagePartList.fireActivePartChanged(WorkbenchPagePartList.java:57) at org.eclipse.ui.internal.PartList.setActivePart(PartList.java:136) at org.eclipse.ui.internal.WorkbenchPage.setActivePart(WorkbenchPage.java:3636) at org.eclipse.ui.internal.WorkbenchPage.requestActivation(WorkbenchPage.java:3159) at org.eclipse.ui.internal.PartPane.requestActivation(PartPane.java:279) at org.eclipse.ui.internal.EditorPane.requestActivation(EditorPane.java:98) at org.eclipse.ui.internal.PartPane.handleEvent(PartPane.java:237) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1077) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1058) at org.eclipse.swt.widgets.Shell.setActiveControl(Shell.java:1447) at org.eclipse.swt.widgets.Shell.WM_MOUSEACTIVATE(Shell.java:2320) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4572) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1610) at org.eclipse.swt.widgets.Shell.windowProc(Shell.java:2061) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.DefWindowProcW(Native Method) at org.eclipse.swt.internal.win32.OS.DefWindowProc(OS.java:2526) at org.eclipse.swt.widgets.Scrollable.callWindowProc(Scrollable.java:80) at org.eclipse.swt.widgets.Control.windowProc(Control.java:4623) at org.eclipse.swt.widgets.Canvas.windowProc(Canvas.java:341) at org.eclipse.swt.widgets.Display.windowProc(Display.java:4985) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:3114) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3749) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2696) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2660) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2494) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) Somewhere you find this: at org.eclipse.team.internal.ui.history.GenericHistoryView.showPageRec(GenericHistoryView.java:649) Regards, Lukas This is reproducible easily It seems to relate to the number of files in commit. Here is how to reproduce: 1. Install Eclipse 3.7 (I used eclipse-jee-indigo-SR1-win32-x86_64.zip) 2. Install latest Egit (from http://download.eclipse.org/egit/updates-nightly) 3. Create a repository with at least a 100 files, one commit. In my cases I used 354 files. 4. Import this into Eclipse. I used Process Explorer to measure the number of GDI objects allocated by Eclipse. 5. Open Eclipse its a low number 210. 6. Open the History View. The GDI numbers are now 660. 7. Select the commit in the history. GDI is now 988 8. Click again on the commit. GDI is now 1319 Every time you click on the commit, the numbers go up. This shows the memory leak. If you have a repository with a lots of file (I have one with 33000 files), you can exhaust the 10K GDI limit with one single click on the commit. One click. (In reply to comment #13) > This is reproducible easily > It seems to relate to the number of files in commit. I don't think it's the same issue that I'm seeing. I can reproduce it in a clean workspace with a repo that has no files and GDI handles is stable at like 500. Hi, we're being hit quite hard by this issue. Searching the web, it seems that using 32bit SWT and forcing the use of specific XULRunner via MOZILLA_FIVE_HOME, might solve it. However, we cannot go this route (need 64bit). Is there any other workaround to this issue? It's making it impossible for us to work with EGit (specifically - the history view) as Eclipse needs to be restarted often due to the handles issue. Thanks Is it always on Windows XP or also Windows 7? (In reply to comment #15) > for us to work with EGit (specifically - the history view) as Eclipse needs > to be restarted often due to the handles issue. Hi Ron, do you actually see a big number of handles if you look at the process using Process Explorer? It's also win 7. Happens to us on Win7. In Windows Explorer, I see the number of total handles (as reported in the status bar) increases when this happens (by about 1000 or more, it's difficult to tell exactly.) Then goes down when Eclipse is force-closed. The number in the "Handles" column of the javaw.exe process does not seem to rise. (of course I meant Process Explorer) Proposed fix pushed to https://git.eclipse.org/r/#/c/5181 Hi Kevin, This won't interfere with your fix, but I thought I would mention something w.r.t. your comment that SWTCommitList can hold 20-30 colors. JFace provides a ResourceManager class that can be used to share colors, only allocating new ones. The common pattern is: ResourceManager parentResourceManager = JFaceResources.getResources(); LocalResourceManager localManager = new LocalResourceManager(parentResourceManager); Image img = localManager.createImage(imgDescriptor); Color clr = localManager.createColor(rgb); When the object (like the SWTCommitList) is disposed it just disposes the localManager. The colors are ref-counted by the main resource manager, and disposed when no longer used. The same technique can be used for images and fonts to share as many common ones as possible. It simplifies disposal and shares as many OS resources as possible within your plugins. PW merged as cda69df69c16345b03f6f182580ed949eb2ecee0 I pulled the latest, containing cda69df69c16345b03f6f182580ed949eb2ecee0 and it's still happening on my PC. As I mentioned previously, I think there are two different issues. One is running out of handles for real (now fixed?) and the other one is the one I reported, where the handle number is stable and SWT throws a SWTError because of a failing CreateWindowEx, see comment 7. I attempted to pull from nightly to see if the fix works for us, but cannot update from there due to the following: (This is after an upgrade to Indigo Service Release 2) An error occurred while collecting items to be installed session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). Multiple problems occurred while downloading. Problems downloading artifact: osgi.bundle,org.eclipse.jgit,2.0.0.201202281711. Unpacking fails because intermediate file is empty: C:\Users\eon\AppData\Local\Temp\work3875807792357039105\p2.optimizers.incoming4218405136153345248.jar Problems downloading artifact: osgi.bundle,org.eclipse.jgit,2.0.0.201202281711. File has invalid content:C:\Users\eon\AppData\Local\Temp\signatureFile5206146613585207703.jar Invalid content:org/eclipse/jgit/blame/BlameResult.class The file "org/eclipse/jgit/blame/BlameResult.class" in the jar "C:\Users\eon\AppData\Local\Temp\signatureFile5206146613585207703.jar" has been tampered! Invalid content:org/eclipse/jgit/ignore/IgnoreNode$MatchResult.class The file "org/eclipse/jgit/ignore/IgnoreNode$MatchResult.class" in the jar "C:\Users\eon\AppData\Local\Temp\signatureFile5206146613585207703.jar" has been tampered! Perhaps the nightly update site is broken? (In reply to comment #25) > I attempted to pull from nightly to see if the fix works for us, but cannot > update from there due to the following: > I see the same problem, I opened bug 372845 PW Apparently this is not resolved, we're still seeing the same behavior with: Eclipse EGit 2.0.0.201203050425 org.eclipse.egit.feature.group Eclipse EGit Eclipse JGit 2.0.0.201203050422 org.eclipse.jgit.feature.group Eclipse JGit from the nightly. (In reply to comment #27) > Apparently this is not resolved, we're still seeing the same behavior with: So you are still getting the "No more handles" exception when the History view is open? What version of Windows are you seeing this on? Yes, I still get this error. As noted, it forces a restart of Eclipse, so we can't work with EGit (specifically - the History view). The version of Windows is "Windows 7 Professional Service Pack 1" 64bit. (In reply to comment #29) > Yes, I still get this error. As noted, it forces a restart of Eclipse, so we > can't work with EGit (specifically - the History view). > > The version of Windows is "Windows 7 Professional Service Pack 1" 64bit. Okay, I will try and reproduce this on Windows 7 Ultimate 64bit which is what I have access too. (In reply to comment #29) > Yes, I still get this error. As noted, it forces a restart of Eclipse, so we > can't work with EGit (specifically - the History view). > > The version of Windows is "Windows 7 Professional Service Pack 1" 64bit. Does the issue usually show up immediately? Or how long does it take before the errors start occurring in terms of clicking around the History view and Repositories view? Actually it took about 30 seconds of clicking around to get the error now. FWIW, the stack trace is here - http://pastebin.com/fwCqzHQz Thanks and please let me know if I can help the investigation in any way (In reply to comment #32) > Actually it took about 30 seconds of clicking around to get the error now. > FWIW, the stack trace is here - http://pastebin.com/fwCqzHQz > > Thanks and please let me know if I can help the investigation in any way Could you try with sleak installed from comment #3 ? As you click around, take snapshots and compare the resources being allocated. Just switching between views should allocate no new resources once you've reached a stable state, for exmaple. PW I'm not seeing anything crazy going on running Sleak with the latest builds, things stay stable as a I switch between repositories. Ron K, approximately how many repositories do you have in the Git Repositories view? And do they have a lot of branches or commits? I'll try the Sleak thing soon (hopefully tomorrow) The repositories view contains 4 respositories. Each one of them contains a couple of local branches, and up to 4 remote tracking branches. (and the commit history is generally quite short) I pushed another fix for colors that were still being leaked: https://git.eclipse.org/r/#/c/5250/ With the latest nightly we haven't been able to reproduce the issue so far. Many thanks! That was a bit premature... it still happens (perhaps less frequently). A new stack trace can be seen here in case it helps: http://pastebin.com/uSJNjBr5 Note, the versions used are: Eclipse EGit 2.0.0.201203060023 org.eclipse.egit.feature.group Eclipse EGit Eclipse JGit 2.0.0.201203060019 org.eclipse.jgit.feature.group Eclipse JGit EGit Mylyn 2.0.0.201203060023 org.eclipse.egit.mylyn.feature.group Eclipse EGit Unfortunately, SLeak is not working for me. After following all the instructions, all it shows is a blank view with a "Snap" button that seems to do nothing. (In reply to comment #40) > Unfortunately, SLeak is not working for me. After following all the > instructions, all it shows is a blank view with a "Snap" button that > seems to do nothing. For sleak to work, you have to launch your eclipse with "-debug debug.file" where the file has: org.eclipse.ui/debug=true org.eclipse.ui/trace/graphics=true PW Updated to the newest nightly - still happens: Eclipse EGit 2.0.0.201203060314 org.eclipse.egit.feature.group Eclipse EGit Eclipse JGit 2.0.0.201203060019 org.eclipse.jgit.feature.group Eclipse JGit EGit Mylyn 2.0.0.201203060314 org.eclipse.egit.mylyn.feature.group Eclipse EGit Updated to the newest nightly - still happens: Eclipse EGit 2.0.0.201203060314 org.eclipse.egit.feature.group Eclipse EGit Eclipse JGit 2.0.0.201203060019 org.eclipse.jgit.feature.group Eclipse JGit EGit Mylyn 2.0.0.201203060314 org.eclipse.egit.mylyn.feature.group Eclipse EGit Sorry for the double post. Anyway, Paul - thanks - I thought it was enough to put these options in the .options file. But trying the "-debug debug.file" way, I still get the same behavior. The problem is not resolved. Finally I have a simple test case and you can easily test with Sleak. The history view has problem with image files. I created a an empty git repository with the following commands. $ git init Initialized empty Git repository in /cygdrive/c/DevEnv/e-wkspc/git-test/git-test/.git/ $ for f in $(seq 100 200);do echo $f >test-$f.png; done $ git add -A $ git commit -m "Add 101 png files" [master (root-commit) a6466d8] Add 100 png files 101 files changed, 101 insertions(+), 0 deletions(-) .. Now I openned Eclipse Git Repository view, with Sleak Enabled. Open History View. Sleak provides: 100 colors, 5 Cursor, 11 Fonts, 88 images, 1 Text layout Link History view with the repository and Sleak informs: 131 colors, 7 Cursors, 15 Fonts, 209 Images, 11 text layout. Click again on the commit and Images goes up to 310. Click again it's 411, 512. Close the history view and the number of images goes to 518 and stay there. It looks that for each image file in the commit detail a new image resource gets created, every time when the commit gets clicked. I will attach the screenshots Created attachment 212344 [details]
SWT resources start
Created attachment 212345 [details]
SWT Resources - history view openned
Created attachment 212346 [details]
SWT Resources - click on commit
Created attachment 212347 [details]
SWT Resources - click 2 on commit
Created attachment 212348 [details]
SWT Resources - click 3 on commit
Created attachment 212349 [details]
SWT Resources - Close history view
(In reply to comment #51) > Created attachment 212349 [details] > SWT Resources - Close history view What build were you using? (In reply to comment #45) > The problem is not resolved. I have pushed another fix here that addresses the leak you experienced in those screenshots. https://git.eclipse.org/r/5315 Version used Eclipse 3.7.2, Egit 2012-03-09-0914, Mylyn Will try again Monday. He latest version (egit_2.0.0.201203110514) fixes the image leak problem. Thanks (In reply to comment #55) > He latest version (egit_2.0.0.201203110514) fixes the image leak problem. > I upgraded to Eclipse EGit 2.0.0.201203110514 org.eclipse.egit.feature.group Eclipse EGit And still have the same leak issue as before. Can't get anything out of Sleak, so I can't say whether it's images or not. Any pointers regarding Sleak or anything else that I can do to help the investigation, please let me know.
I found a very quick and direct way to reproduce the issue, maybe this will help:
1- Have the following 2 views visible in Eclipse - "Git Repositories" and "Properties".
2- The "History" view should *not* be visible
3- Fully close Eclipse and restart it ("File->Restart")
4- After Eclipse came up, click In the Git Repos view on some repository
5- Open the History view. It will be blank (contrary to expectation)
6- Click anywhere in the Git Repos view --> Boom.
Notes:
1) The first 2 steps are just to make sure that when Eclipse comes up, the views
are as needed for seeing the issue.
2) In step 2, the History view should not be closed, just not visible - this is
the purpose of viewing the "Properties" view in step 1, as it is in the same tab drawer as the History view. Opening the History view in step 5 means just
make it visible by clicking on its tab.
HTH
(In reply to comment #57) > I found a very quick and direct way to reproduce the issue, maybe this will > help: I can also reproduce this with Eclipse 3.8.0-I20120228-0800 and Egit 2.0.0.201203110422. (In reply to comment #57) > 6- Click anywhere in the Git Repos view --> Boom. The "Boom" here refers to the "No more handles" exception right? Not a crash or freeze. (In reply to comment #59) > (In reply to comment #57) > > 6- Click anywhere in the Git Repos view --> Boom. > > The "Boom" here refers to the "No more handles" exception right? Not a crash or > freeze. Yes, it's the exception I'm seeing. Similar stack too org.eclipse.swt.SWTError: No more handles at org.eclipse.swt.SWT.error(SWT.java:4366) at org.eclipse.swt.SWT.error(SWT.java:4255) at org.eclipse.swt.SWT.error(SWT.java:4226) at org.eclipse.swt.widgets.Widget.error(Widget.java:468) at org.eclipse.swt.widgets.Control.createHandle(Control.java:704) at org.eclipse.swt.widgets.Sash.createHandle(Sash.java:119) at org.eclipse.swt.widgets.Control.createWidget(Control.java:744) at org.eclipse.swt.widgets.Control.<init>(Control.java:112) at org.eclipse.swt.widgets.Sash.<init>(Sash.java:77) at org.eclipse.swt.custom.SashForm.createSash(SashForm.java:99) at org.eclipse.swt.custom.SashFormLayout.layout(SashFormLayout.java:115) ... ... (Composite.java:1126) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1264) at org.eclipse.swt.widgets.Composite.updateLayout(Composite.java:1249) at org.eclipse.swt.widgets.Composite.layout(Composite.java:664) at org.eclipse.swt.widgets.Composite.layout(Composite.java:622) at org.eclipse.ui.part.PageBook.showPage(PageBook.java:103) at org.eclipse.ui.part.PageBookView.showPageRec(PageBookView.java:979) at org.eclipse.team.internal.ui.history.GenericHistoryView.showPageRec(GenericHistoryView.java:512) at org.eclipse.ui.part.PageBookView.partActivated(PageBookView.java:756) (In reply to comment #59) > (In reply to comment #57) > > 6- Click anywhere in the Git Repos view --> Boom. > > The "Boom" here refers to the "No more handles" exception right? Not a crash or > freeze. As noted by Marc-Andre, yes. "No more handles". Kevin, any luck reproducing this case? (In reply to comment #62) > Kevin, any luck reproducing this case? I have not had success, several leaks have been fixed and I don't see any more currently happening when using the History view with Sleak. Just to confirm, this is still happening with the very latest nightlies? 2.0.0.201203211722 or above (In reply to comment #64) > Just to confirm, this is still happening with the very latest nightlies? > 2.0.0.201203211722 or above Yes, still happening with 2.0.0.201203211826 using Ron's last repro steps. I'm not seeing an increase in handles. (In reply to comment #65) > Yes, still happening with 2.0.0.201203211826 using Ron's last repro steps. I'm > not seeing an increase in handles. On XP or Windows 7 or both? I tested on Windows 7, Vista and XP. It happened only on Windows 7 so far. It looks like it's a SWT bug in Win 7, IMO. Especially since it happened for me with a clean workspace, an empty repo and no noticeable handle increase. I got this on XP when doing the same steps, but it looks like a different bug altogether: java.lang.NullPointerException at org.eclipse.jgit.storage.file.ByteArrayWindow.setInput(ByteArrayWindow.java:78) at org.eclipse.jgit.storage.file.ByteWindow.setInput(ByteWindow.java:128) at org.eclipse.jgit.storage.file.WindowCursor.inflate(WindowCursor.java:286) at org.eclipse.jgit.storage.file.PackFile.decompress(PackFile.java:308) at org.eclipse.jgit.storage.file.PackFile.load(PackFile.java:697) at org.eclipse.jgit.storage.file.PackFile.get(PackFile.java:227) at org.eclipse.jgit.storage.file.ObjectDirectory.openObject1(ObjectDirectory.java:439) at org.eclipse.jgit.storage.file.FileObjectDatabase.openObjectImpl1(FileObjectDatabase.java:172) at org.eclipse.jgit.storage.file.FileObjectDatabase.openObject(FileObjectDatabase.java:157) at org.eclipse.jgit.storage.file.WindowCursor.open(WindowCursor.java:122) at org.eclipse.jgit.revwalk.RevWalk.getCachedBytes(RevWalk.java:855) at org.eclipse.jgit.revwalk.RevCommit.parseHeaders(RevCommit.java:136) at org.eclipse.jgit.revwalk.PendingGenerator.next(PendingGenerator.java:148) at org.eclipse.jgit.revwalk.TopoSortGenerator.<init>(TopoSortGenerator.java:78) at org.eclipse.jgit.revwalk.StartGenerator.next(StartGenerator.java:163) at org.eclipse.jgit.revwalk.RevWalk.next(RevWalk.java:420) at org.eclipse.jgit.revplot.PlotWalk.next(PlotWalk.java:132) at org.eclipse.jgit.revwalk.RevCommitList.fillTo(RevCommitList.java:305) at org.eclipse.egit.ui.internal.history.GenerateHistoryJob.run(GenerateHistoryJob.java:68) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) I tried the same "experiment" mentioned in Comment 7 and it does prevent the SWT error from happening (still with the steps from Comment 57). Not sure how that helps yet but it might be a hint... And have you seen this with Eclipse 3.7.2 as well? Looks like the initial report was on Eclipse 3.7.1 (In reply to comment #69) > And have you seen this with Eclipse 3.7.2 as well? Looks like the initial > report was on Eclipse 3.7.1 Yes, I get the error using both reproduction steps (initial report and comment 57) with Eclipse 3.7.2 + EGit 2.0.0.201203220822, Windows 7. I got the following similar error just now on EGit 1.3. Eclipse actually crashed 3 times today when using EGit (and doing not much else), but I only have a stack trace for the latest one: Version: Indigo Service Release 2 Build id: 20120216-1857 org.eclipse.swt.SWTError: No more handles at org.eclipse.swt.SWT.error(SWT.java:4308) at org.eclipse.swt.SWT.error(SWT.java:4197) at org.eclipse.swt.SWT.error(SWT.java:4168) at org.eclipse.swt.internal.ImageList.copyWithAlpha(ImageList.java:179) at org.eclipse.swt.internal.ImageList.set(ImageList.java:409) at org.eclipse.swt.internal.ImageList.add(ImageList.java:70) at org.eclipse.swt.widgets.Table.imageIndex(Table.java:2930) at org.eclipse.swt.widgets.TableItem.setImage(TableItem.java:1100) at org.eclipse.jface.viewers.TableViewerRow.setImage(TableViewerRow.java:134) at org.eclipse.jface.viewers.ViewerCell.setImage(ViewerCell.java:169) at org.eclipse.jface.viewers.TableColumnViewerLabelProvider.update(TableColumnViewerLabelProvider.java:71) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:152) at org.eclipse.jface.viewers.AbstractTableViewer.doUpdateItem(AbstractTableViewer.java:399) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:485) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2167) at org.eclipse.jface.viewers.AbstractTableViewer.createItem(AbstractTableViewer.java:277) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefreshAll(AbstractTableViewer.java:757) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:649) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:636) at org.eclipse.jface.viewers.AbstractTableViewer$2.run(AbstractTableViewer.java:592) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1443) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1404) at org.eclipse.jface.viewers.AbstractTableViewer.inputChanged(AbstractTableViewer.java:590) at org.eclipse.egit.ui.internal.history.CommitFileDiffViewer.inputChanged(CommitFileDiffViewer.java:394) at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:280) at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1690) at org.eclipse.egit.ui.internal.history.GitHistoryPage$4.selectionChanged(GitHistoryPage.java:841) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:888) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:886) at org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1726) at org.eclipse.jface.viewers.TableViewer.setSelection(TableViewer.java:158) at org.eclipse.egit.ui.internal.history.CommitGraphTable.selectCommit(CommitGraphTable.java:371) at org.eclipse.egit.ui.internal.history.CommitGraphTable.selectCommitStored(CommitGraphTable.java:362) at org.eclipse.egit.ui.internal.history.GitHistoryPage.showHead(GitHistoryPage.java:1221) at org.eclipse.egit.ui.internal.history.GitHistoryPage.inputSet(GitHistoryPage.java:1198) at org.eclipse.team.ui.history.HistoryPage.setInput(HistoryPage.java:59) at org.eclipse.egit.ui.internal.history.GitHistoryPage.setInput(GitHistoryPage.java:1066) at org.eclipse.team.internal.ui.history.GenericHistoryView.showHistoryPageFor(GenericHistoryView.java:738) at org.eclipse.team.internal.ui.history.GenericHistoryView.showHistory(GenericHistoryView.java:969) at org.eclipse.team.internal.ui.history.GenericHistoryView.editorActivated(GenericHistoryView.java:892) at org.eclipse.team.internal.ui.history.GenericHistoryView$1.partActivated(GenericHistoryView.java:362) at org.eclipse.ui.internal.PartListenerList$1.run(PartListenerList.java:72) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.runtime.Platform.run(Platform.java:888) at org.eclipse.ui.internal.PartListenerList.fireEvent(PartListenerList.java:57) at org.eclipse.ui.internal.PartListenerList.firePartActivated(PartListenerList.java:70) at org.eclipse.ui.internal.PartService.firePartActivated(PartService.java:187) at org.eclipse.ui.internal.PartService.setActivePart(PartService.java:306) at org.eclipse.ui.internal.WorkbenchPagePartList.fireActivePartChanged(WorkbenchPagePartList.java:57) at org.eclipse.ui.internal.PartList.setActivePart(PartList.java:136) at org.eclipse.ui.internal.WorkbenchPage.setActivePart(WorkbenchPage.java:3636) at org.eclipse.ui.internal.WorkbenchPage.internalActivate(WorkbenchPage.java:691) at org.eclipse.ui.internal.WorkbenchPage.activate(WorkbenchPage.java:663) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2957) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2850) at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:2842) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2793) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2789) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2773) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2764) at org.eclipse.ui.internal.NavigationHistoryEntry.restoreLocation(NavigationHistoryEntry.java:66) at org.eclipse.ui.internal.NavigationHistory.gotoEntry(NavigationHistory.java:455) at org.eclipse.ui.internal.NavigationHistory.shiftCurrentEntry(NavigationHistory.java:537) at org.eclipse.ui.internal.NavigationHistoryAction$2.widgetSelected(NavigationHistoryAction.java:119) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:240) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4165) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3754) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2701) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2665) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) I am running Eclipse bootstrapped, and twice in the last two days, using the EGit history view in my base Eclipse has caused the history view in my *bootstrapped* Eclipse to get a " No more handles" error. The really odd thing is that this then causes my bootstrapped Eclipse to shut down (not crash, but actually exit cleanly with a dialog). Created attachment 215731 [details]
stack trace from bootstrapped Eclipse
Created attachment 221065 [details] SWT Detective output on the History view I'd like to recommend this blog on 'No more handles'. It was extremely useful to me working in WTP Dali with our JPA views that use a lot of SWT widgets. You might be coming up against the max number of USER handles instead of GDIs. It looks like you've fixed several Image and Color leaks with this bug. Sleak is very useful for finding those, but does not help with USER handles. Every instance of o.e.swt.widgets.Control creates a USER handle. This blog helps explain things and also has a very useful tool called SWT Detective that was based on SWTTools SWT Spy http://www.subshell.com/en/subshell/blog/investigating-user-handles-with-the-swt-detective100.html I've attached a readout from SWT Detective on the History view showing 76 children objects(not all that many but it adds up quick, each commit viewer uses 50 Controls). It shows you every Composite, Label, ToolBar, etc that was created for the History view. The particular stack trace people have posted shows the creation of a SashForm being the last straw before the 'No More Handles'. I don't really understand how people are running out of handles so early in an Eclipse Session, but maybe this will help diagnose the problem. I just tried again using the latest 4.3 build (http://download.eclipse.org/eclipse/downloads/drops4/N20121125-2000/) and the latest EGit nightly build and can't reproduce the "no more handles" problem with the steps from comment 57. closing as this seems to be no longer reproducable |