Eclipse Community Forums: EGit » Newest JGit broken?

Help

Home

Home » Eclipse Projects » EGit » Newest JGit broken?

Show: Today's Messages :: Show Polls :: Message Navigator

Newest JGit broken? [message #782684]

Tue, 24 January 2012 08:23

Eike Stepper

Messages: 5681
Registered: July 2009

Senior Member

Hi,

I can not stage changes anymore with JGit 1.3.0.201201201920. The following error occurs even with a fresh clone:

org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of add command
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:216)
at org.eclipse.egit.ui.internal.staging.StagingView.stage(StagingView.java:977)
at org.eclipse.egit.ui.internal.staging.StagingView.access$6(StagingView.java:946)
at org.eclipse.egit.ui.internal.staging.StagingView$7.drop(StagingView.java:464)
at org.eclipse.swt.dnd.DNDListener.handleEvent(DNDListener.java:90)
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:1062)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:774)
at org.eclipse.swt.dnd.DropTarget.Drop(DropTarget.java:456)
at org.eclipse.swt.dnd.DropTarget.Drop_64(DropTarget.java:392)
at org.eclipse.swt.dnd.DropTarget$3.method6(DropTarget.java:260)
at org.eclipse.swt.internal.ole.win32.COMObject.callback6(COMObject.java:119)
at org.eclipse.swt.internal.ole.win32.COM.DoDragDrop(Native Method)
at org.eclipse.swt.dnd.DragSource.drag(DragSource.java:363)
at org.eclipse.swt.dnd.DragSource.access$0(DragSource.java:289)
at org.eclipse.swt.dnd.DragSource$1.handleEvent(DragSource.java:172)
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:352)
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:624)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:579)
at org.eclipse.equinox.launcher.Main.run(Main.java:1431)
at org.eclipse.equinox.launcher.Main.main(Main.java:1407)
Caused by: java.io.EOFException: Input did not match supplied length. 720 bytes are missing.
at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.shortInput(ObjectDirectoryInserter.java:237)
at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.toTemp(ObjectDirectoryInserter.java:168)
at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.insert(ObjectDirectoryInserter.java:105)
at org.eclipse.jgit.api.AddCommand.call(AddCommand.java:183)
... 42 more

Is that a known issue?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Newest JGit broken? [message #782721 is a reply to message #782684]

Tue, 24 January 2012 09:48

Christian Halstrick

Messages: 18
Registered: July 2009

Junior Member

I don't know about that. This sounds severe. I would really file a bug against JGit at https://bugs.eclipse.org/bugs/.
Are you maybe trying out auto-crlf features. If you file a bug please tell about your settings (maybe attach a 'git config -l' output)

Report message to a moderator

Re: Newest JGit broken? [message #783234 is a reply to message #782721]

Wed, 25 January 2012 10:29

Matthias Sohn

Messages: 646
Registered: July 2009

Senior Member

I tried to stage a simple change in staging view using latest nightly JGit 1.3.0.201201241920 and EGit 1.3.0.201201241924 and this works fine.

So we need more details about your configuration.

ObjectDirectoryInserter throws this exception if the file length of the file being added doesn't match the length returned by the Eclipse resource model if the file is mapped to an Eclipse resource (which is the case for all files except those not contained in the workspace like files which are in the repository working tree but outside eclipse projects) or the length returned by java.io.File.length() for files not mapped to the Eclipse resource model. So maybe the length cached by Eclipse doesn't match the file length on disk. This may happen if you modified the file outside Eclipse.

Report message to a moderator

Re: Newest JGit broken? [message #783447 is a reply to message #783234]

Wed, 25 January 2012 18:28

Robin Rosenberg

Messages: 332
Registered: July 2009

Senior Member

Matthias Sohn skrev 2012-01-25 11.29:
> I tried to stage a simple change in staging view using latest nightly JGit 1.3.0.201201241920 and EGit 1.3.0.201201241924 and this works fine.
>
> So we need more details about your configuration.
>
> ObjectDirectoryInserter throws this exception if the file length of the file being added doesn't match the length returned by the Eclipse resource model if the file is
> mapped to an Eclipse resource (which is the case for all files except those not contained in the workspace like files which are in the repository working tree but outside
> eclipse projects) or the length returned by java.io.File.length() for files not mapped to the Eclipse resource model. So maybe the length cached by Eclipse doesn't match
> the file length on disk. This may happen if you modified the file outside Eclipse.

It's not that simple. I was able to replicate this. See http://egit.eclipse.org/r/#/c/4998/1 for a
a test and workaround, a workaround because it does not scale to huge large file well. The ugliness
is that all data is always buffered into memory as a huge byte array, even for binary files.

Unfortunately the blob format has length first and it is compressed, so I see no way of e.g.
leaving a slot at the start of the blob, stream the compressed data and go back and update the
length when we know it. We have to read at least 8k before creating the blob.

-- robin

Report message to a moderator

Re: Newest JGit broken? [message #783719 is a reply to message #782721]

Thu, 26 January 2012 09:40

Eike Stepper

Messages: 5681
Registered: July 2009

Senior Member

Thank you, guys!

I submitted https://bugs.eclipse.org/369780

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Am 24.01.2012 10:48, schrieb Christian Halstrick:
> I don't know about that. This sounds severe. I would really file a bug against JGit at https://bugs.eclipse.org/bugs/.
> Are you maybe trying out auto-crlf features. If you file a bug please tell about your settings (maybe attach a 'git
> config -l' output)

Report message to a moderator

Re: Newest JGit broken? [message #814227 is a reply to message #783719]

Tue, 06 March 2012 07:29

Glen Ihrig

Messages: 1
Registered: March 2012

Junior Member

I have experienced this issue

Mac OS X 10.6.8
SpringSource Tool Suite 2.8.1 RELEASE
EGit 1.3.0.201202151440-r

It happened for me after renaming a project and carefully updating all affected files (several hundred files changed). After this large change, many packages in my project indicated not being tracked. They were decorated with the '?'. The error condition happened when attempting to commit or add from the project root folder.

The problem seems to be related to large amounts of data as Robin Rosenberg suggested.

I found two simple work-arounds that got me back into production:

1. Using EGit - Add files a few at a time. I was able to commit all changes in a single pass after adding in small chunks.

2. Using Git - After tiring of many small 'Add to Index' cycles I opened the project root folder in a terminal and executed

git add .

Problem solved.

Report message to a moderator

Previous Topic:	[EGIT 1.3] : NPE at import
Next Topic:	Exception caught during execution of commit command

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Mar 05 02:36:30 GMT 2015

.:: Contact :: Home ::.