Bug 368475

Comment 1 Jens Baumgart 2012-01-13 03:29:30 EST

I have some questions on the problem:

1. How big is your Git Repository (number of files)
2. How much heap is assigned to your Eclipse instance

To save memory, the following preference should be disabled for big repositories:

Git->Views->History View->Show tag sequence

Comment 2 Ian Bull 2012-01-13 15:17:48 EST

I also hit an OOME with the synch. view (different stack). See bug 368585.

I have 200M allocated to my heap, and 8746 files in my git repository (according to find . | wc).

Comment 3 Ian Bull 2012-01-13 15:18:31 EST

Sorry, I mean to say "similar stack".

Comment 4 Sam Davis 2012-03-30 13:44:16 EDT

I just had EGit crash my Eclipse, which is almost a daily occurence, but this time I at least was able to get a stack trace. This happened when selecting a branch in the repositories view to see it in the history view. I am running EGit 1.3 with the following memory settings: -Xms40m -Xmx1024m -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=64m. Ever since I started using EGit, Eclipse is usually (~75% of the time) on the brink of running out of heap space, which is ridiculous given that I am giving it 1GB of heap, which is the maximum stable amount for 32 bit Eclipse on Windows.


!ENTRY org.eclipse.mylyn.context.core 4 0 2012-03-30 10:32:05.550
!MESSAGE Could not save activity history
!STACK 0
java.lang.OutOfMemoryError: Java heap space

!ENTRY org.eclipse.ui 4 0 2012-03-30 10:32:05.558
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.OutOfMemoryError: Java heap space
	at org.eclipse.jgit.storage.file.PackReverseIndex.<init>(PackReverseIndex.java:104)
	at org.eclipse.jgit.storage.file.PackFile.getReverseIdx(PackFile.java:1025)
	at org.eclipse.jgit.storage.file.PackFile.findObjectForOffset(PackFile.java:289)
	at org.eclipse.jgit.storage.file.LargePackedDeltaObject.getObjectId(LargePackedDeltaObject.java:263)
	at org.eclipse.jgit.storage.file.LargePackedDeltaObject.openStream(LargePackedDeltaObject.java:174)
	at org.eclipse.jgit.lib.ObjectLoader.getCachedBytes(ObjectLoader.java:187)
	at org.eclipse.jgit.revwalk.RevWalk.getCachedBytes(RevWalk.java:861)
	at org.eclipse.jgit.revwalk.RevWalk.parseNew(RevWalk.java:825)
	at org.eclipse.jgit.revwalk.RevWalk.parseAny(RevWalk.java:811)
	at org.eclipse.egit.ui.internal.history.GitHistoryPage.markStartRef(GitHistoryPage.java:1851)
	at org.eclipse.egit.ui.internal.history.GitHistoryPage.markStartAllRefs(GitHistoryPage.java:1838)
	at org.eclipse.egit.ui.internal.history.GitHistoryPage.setWalkStartPoints(GitHistoryPage.java:1677)
	at org.eclipse.egit.ui.internal.history.GitHistoryPage.initAndStartRevWalk(GitHistoryPage.java:1498)
	at org.eclipse.egit.ui.internal.history.GitHistoryPage.inputSet(GitHistoryPage.java:1191)
	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.access$3(GenericHistoryView.java:965)
	at org.eclipse.team.internal.ui.history.GenericHistoryView$3.selectionChanged(GenericHistoryView.java:435)
	at org.eclipse.ui.internal.AbstractSelectionService.firePostSelection(AbstractSelectionService.java:179)
	at org.eclipse.ui.internal.AbstractSelectionService.setActivePart(AbstractSelectionService.java:289)
	at org.eclipse.ui.internal.WorkbenchPagePartList.fireActivePartChanged(WorkbenchPagePartList.java:60)
	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.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)

!ENTRY org.eclipse.ui 4 0 2012-03-30 10:32:05.565
!MESSAGE Error occurred during status handling
!STACK 0
java.lang.OutOfMemoryError: Java heap space

Exception in thread "Timer-0" 
java.lang.OutOfMemoryError: Java heap space
Mar 30, 2012 10:32:05 AM sun.rmi.transport.tcp.TCPTransport$AcceptLoop executeAcceptLoop
WARNING: RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9654] throws
java.lang.OutOfMemoryError: Java heap space
Exception in thread "JmDNS.SocketListener" java.lang.IllegalStateException: Timer already cancelled.
	at java.util.Timer.sched(Unknown Source)
	at java.util.Timer.schedule(Unknown Source)
	at javax.jmdns.impl.JmDNSImpl.schedule(JmDNSImpl.java:949)
	at javax.jmdns.impl.tasks.Responder.start(Responder.java:86)
	at javax.jmdns.impl.JmDNSImpl.handleQuery(JmDNSImpl.java:886)
	at javax.jmdns.impl.SocketListener.run(SocketListener.java:64)
	at java.lang.Thread.run(Unknown Source)

Comment 5 Sam Davis 2012-03-30 13:45:46 EDT

Created attachment 213401 [details]
error dialog

Comment 6 Robin Rosenberg 2012-06-19 20:00:43 EDT

(In reply to comment #2)
> I also hit an OOME with the synch. view (different stack). See bug 368585.
> 
> I have 200M allocated to my heap, and 8746 files in my git repository
> (according to find . | wc).

200MB is very little to work with Eclipse in general. At some point having
too little memory *will* result in out-of-memory errors. Maybe git is just
the last pieces needed to make your Eclipse fail.

Comment 7 Robin Rosenberg 2012-09-08 19:47:59 EDT

If you can repeat this, you should use record how much there is in your heap
before the history view blows up your eclipse. Then we may be able to
determine if EGit uses absurd amounts of memory.

Comment 8 Ian Bull 2012-09-10 13:07:17 EDT

(In reply to comment #7)
> If you can repeat this, you should use record how much there is in your heap
> before the history view blows up your eclipse. Then we may be able to
> determine if EGit uses absurd amounts of memory.

To be honest, things have improved a great deal with Juno.  I move between Eclipse 3.7 (with an older version of EGit), 4.2 and Kepler, and >= 4.2 is much, much better.  

Unfortunately if I leave the history view open, and move back to an older version, Eclipse will crash -- but that's certainly not the use case we should worry about. I will keep an eye out and post any information if Eclipse crashes.

Thanks for all the great work Robin.

Comment 9 Martin Oberhuber 2013-03-10 01:43:07 EST

Not sure if it helps much in the egit/jgit case, but in general the Eclipse Memory Analyzer is a great tool. A heap dump can be obtained with

-vmargs -XX:+HeapDumpOnOutOfMemoryError

Comment 10 Matthias Sohn 2013-09-10 05:29:18 EDT

(In reply to Ian Bull from comment #8)
> (In reply to comment #7)
> > If you can repeat this, you should use record how much there is in your heap
> > before the history view blows up your eclipse. Then we may be able to
> > determine if EGit uses absurd amounts of memory.
> 
> To be honest, things have improved a great deal with Juno.  I move between
> Eclipse 3.7 (with an older version of EGit), 4.2 and Kepler, and >= 4.2 is
> much, much better.  
> 
> Unfortunately if I leave the history view open, and move back to an older
> version, Eclipse will crash -- but that's certainly not the use case we
> should worry about. I will keep an eye out and post any information if
> Eclipse crashes.
> 
> Thanks for all the great work Robin.

We have implemented incremental loading of history in EGit 2.0 which was shipped with Juno [1], this dramatically reduces its memory consumption. Though note that this incremental loading is disabled when you have enabled the history view's find toolbar.

I would suggest we close this bug for now since the incremental loading should avoid out of memory errors in most cases.

[1] http://wiki.eclipse.org/EGit/New_and_Noteworthy/2.0#History_View_Improvements

Comment 11 Matthias Sohn 2013-09-10 05:30:30 EDT

incremental loading of history was introduced in 2.0