Comment 1 Marc-André Laperle 2011-12-11 01:20:27 EST

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.

Comment 2 Matthias Sohn 2011-12-11 17:36:14 EST

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.

Comment 3 Paul Webster 2011-12-11 18:41:21 EST

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

Comment 4 Marc-André Laperle 2011-12-12 01:25:04 EST

I couldn't reproduce it on separate Vista PC and Ubuntu 11.4. I'll try on a second Windows 7 PC tomorrow.

Comment 5 Marc-André Laperle 2011-12-12 12:13:51 EST

(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.

Comment 6 Matthias Sohn 2011-12-13 08:27:47 EST

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.

Comment 7 Marc-André Laperle 2011-12-23 01:36:23 EST

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?

Comment 8 Marc-André Laperle 2012-01-09 11:45:53 EST

Anyone else CC'd seeing this bug?

Comment 9 Lukas Olbrich 2012-01-09 12:24:18 EST

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.

Comment 10 Lukas Olbrich 2012-01-09 12:45:06 EST

sry, my fault with the wrong version, just updated to:

Eclipse EGit 1.2.0.201112221803-r

Comment 11 Kevin Sawicki 2012-01-09 12:49:34 EST

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)

Comment 12 Lukas Olbrich 2012-01-10 04:38:56 EST

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

Comment 13 Adalbert Homa 2012-02-13 20:01:06 EST

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.

Comment 14 Marc-André Laperle 2012-02-13 21:07:32 EST

(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.

Comment 15 Ron K 2012-02-28 11:43:25 EST

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

Comment 16 Kevin Sawicki 2012-02-28 11:56:39 EST

Is it always on Windows XP or also Windows 7?

Comment 17 Marc-André Laperle 2012-02-28 11:57:50 EST

(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?

Comment 18 Lukas Olbrich 2012-02-28 12:21:23 EST

It's also win 7.

Comment 19 Ron K 2012-02-28 12:26:57 EST

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.

Comment 20 Ron K 2012-02-28 12:27:27 EST

(of course I meant Process Explorer)

Comment 21 Kevin Sawicki 2012-02-28 13:32:37 EST

Proposed fix pushed to https://git.eclipse.org/r/#/c/5181

Comment 22 Paul Webster 2012-02-28 13:57:47 EST

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

Comment 23 Matthias Sohn 2012-02-28 18:59:17 EST

merged as cda69df69c16345b03f6f182580ed949eb2ecee0

Comment 24 Marc-André Laperle 2012-02-29 01:35:19 EST

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.

Comment 25 Ron K 2012-02-29 03:51:49 EST

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?

Comment 26 Paul Webster 2012-02-29 07:55:40 EST

(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

Comment 27 Ron K 2012-03-05 05:29:29 EST

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.

Comment 28 Kevin Sawicki 2012-03-05 10:57:54 EST

(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?

Comment 29 Ron K 2012-03-05 11:15:26 EST

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.

Comment 30 Kevin Sawicki 2012-03-05 11:18:23 EST

(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.

Comment 31 Kevin Sawicki 2012-03-05 11:28:16 EST

(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?

Comment 32 Ron K 2012-03-05 11:36:51 EST

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

Comment 33 Paul Webster 2012-03-05 11:43:58 EST

(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

Comment 34 Kevin Sawicki 2012-03-05 12:03:06 EST

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?

Comment 35 Ron K 2012-03-05 12:39:42 EST

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.

Comment 36 Ron K 2012-03-05 12:41:06 EST

(and the commit history is generally quite short)

Comment 37 Kevin Sawicki 2012-03-05 14:12:27 EST

I pushed another fix for colors that were still being leaked: https://git.eclipse.org/r/#/c/5250/

Comment 38 Ron K 2012-03-06 03:03:27 EST

With the latest nightly we haven't been able to reproduce the issue so far.

Many thanks!

Comment 39 Ron K 2012-03-06 03:07:47 EST

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

Comment 40 Ron K 2012-03-06 04:27:34 EST

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.

Comment 41 Paul Webster 2012-03-06 06:04:47 EST

(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

Comment 42 Ron K 2012-03-06 06:12:17 EST

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

Comment 43 Ron K 2012-03-06 06:12:34 EST

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

Comment 44 Ron K 2012-03-06 06:17:58 EST

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.

Comment 45 Adalbert Homa 2012-03-08 22:17:11 EST

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

Comment 46 Adalbert Homa 2012-03-08 22:18:26 EST

Created attachment 212344 [details]
SWT resources start

Comment 47 Adalbert Homa 2012-03-08 22:19:11 EST

Created attachment 212345 [details]
SWT Resources - history view openned

Comment 48 Adalbert Homa 2012-03-08 22:19:48 EST

Created attachment 212346 [details]
SWT Resources - click on commit

Comment 49 Adalbert Homa 2012-03-08 22:20:22 EST

Created attachment 212347 [details]
SWT Resources - click 2 on commit

Comment 50 Adalbert Homa 2012-03-08 22:21:44 EST

Created attachment 212348 [details]
SWT Resources - click 3 on commit

Comment 51 Adalbert Homa 2012-03-08 22:22:24 EST

Created attachment 212349 [details]
SWT Resources - Close history view

Comment 52 Kevin Sawicki 2012-03-10 13:04:27 EST

(In reply to comment #51)
> Created attachment 212349 [details]
> SWT Resources - Close history view

What build were you using?

Comment 53 Kevin Sawicki 2012-03-10 14:09:14 EST

(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

Comment 54 Adalbert Homa 2012-03-10 17:14:31 EST

Version used Eclipse 3.7.2, Egit 2012-03-09-0914, Mylyn

Will try again Monday.

Comment 55 Adalbert Homa 2012-03-11 11:03:07 EDT

He latest version (egit_2.0.0.201203110514) fixes the image leak problem.

Thanks

Comment 56 Ron K 2012-03-11 11:29:29 EDT

(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.

Comment 57 Ron K 2012-03-11 13:50:04 EDT

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

Comment 58 Marc-André Laperle 2012-03-11 14:14:39 EDT

(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.

Comment 59 Kevin Sawicki 2012-03-11 14:17:23 EDT

(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.

Comment 60 Marc-André Laperle 2012-03-11 16:39:55 EDT

(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)

Comment 61 Ron K 2012-03-12 03:19:48 EDT

(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".

Comment 62 Marc-André Laperle 2012-03-21 21:04:42 EDT

Kevin, any luck reproducing this case?

Comment 63 Kevin Sawicki 2012-03-21 21:06:33 EDT

(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.

Comment 64 Kevin Sawicki 2012-03-21 21:20:41 EDT

Just to confirm, this is still happening with the very latest nightlies? 2.0.0.201203211722 or above

Comment 65 Marc-André Laperle 2012-03-22 00:36:00 EDT

(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.

Comment 66 Kevin Sawicki 2012-03-22 01:09:52 EDT

(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?

Comment 67 Marc-André Laperle 2012-03-22 01:44:52 EDT

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)

Comment 68 Marc-André Laperle 2012-03-22 02:27:17 EDT

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...

Comment 69 Kevin Sawicki 2012-03-22 11:50:46 EDT

And have you seen this with Eclipse 3.7.2 as well? Looks like the initial report was on Eclipse 3.7.1

Comment 70 Marc-André Laperle 2012-03-22 19:25:12 EDT

(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.

Comment 71 Sam Davis 2012-05-15 18:59:18 EDT

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)

Comment 72 Sam Davis 2012-05-16 14:46:52 EDT

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).

Comment 73 Sam Davis 2012-05-16 14:47:31 EDT

Created attachment 215731 [details]
stack trace from bootstrapped Eclipse

Comment 74 Karen Butzke 2012-09-13 16:53:52 EDT

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.

Comment 75 Dani Megert 2012-11-26 09:14:28 EST

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.

Comment 76 Matthias Sohn 2013-06-18 09:35:43 EDT

closing as this seems to be no longer reproducable