Community
Participate
Working Groups
I have a Git repository containing a number of Git LFS track files; The .gitattrributes entry for the LFS files is ``` third-party/**/*.jar filter=lfs diff=lfs merge=lfs -text ``` When I attempt to clone the repository from Eclipse, the clone hangs at 88% complete. In the local repository directory, I only see a .git folder and the following empty file (size 0 bytes): ``` <repository-root>\third-party\dbb-toolkit-1.0.7\groovy-2.4.12\indy\._groovy-swing-2.4.12-indy.jar8633465030270662044.tmp ``` The git-lfs command should be on system PATH when starting Eclipse. I don't see any Egit relate messages in the Eclipse error log except for the following warning: ``` c:\Users\GeoffAlexander\Documents\Nirvana\ddb-enablement\issues\66>git clone ssh://git@github.ibm.com/zosdevtk/dbb-buildscripts -b master Cloning into 'dbb-buildscripts'... remote: Enumerating objects: 49, done. remote: Counting objects: 100% (49/49), done. remote: Compressing objects: 100% (31/31), done. remote: Total 1540 (delta 25), reused 20 (delta 12), pack-reused 1491 Receiving objects: 100% (1540/1540), 21.90 MiB | 10.30 MiB/s, done. Resolving deltas: 100% (725/725), done. Updating files: 100% (93/93), done. Filtering content: 100% (38/38), 28.96 MiB | 8.83 MiB/s, done. ``` The same repository clones just fine using the git command: ``` c:\Users\GeoffAlexander\Documents\Nirvana\ddb-enablement\issues\66>git clone ssh://git@github.ibm.com/zosdevtk/dbb-buildscripts -b master Cloning into 'dbb-buildscripts'... remote: Enumerating objects: 49, done. remote: Counting objects: 100% (49/49), done. remote: Compressing objects: 100% (31/31), done. remote: Total 1540 (delta 25), reused 20 (delta 12), pack-reused 1491 Receiving objects: 100% (1540/1540), 21.90 MiB | 10.30 MiB/s, done. Resolving deltas: 100% (725/725), done. Updating files: 100% (93/93), done. Filtering content: 100% (38/38), 28.96 MiB | 8.83 MiB/s, done. ``` I'm running Egit 5.7.0 under Eclipse 2019-06 on Windows 10. I'm also have Git LFS 2.9.0 installed. How can I further debug this problem?
are you sure you have pasted the correct warning from egit? Looks like you pasted two time native git command.
I did have a copy / paste problem with the Egit warning - that's hat I get for open the bug at 4:00 AM. Here's the actual EGit warning: ``` eclipse.buildId=4.12.0.I20190605-1800 java.fullversion=8.0.5.36 - pwa6480sr5fp36-20190510_01(SR5 FP36) JRE 1.8.0 Windows 8 amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled) OpenJ9 - 46e57f9 OMR - 06a046a IBM - 0b909bf BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US org.eclipse.egit.ui Warning Tue Mar 24 03:24:20 EDT 2020 Warning: The environment variable HOME is not set. The following directory will be used to store the Git user global configuration and to define the default location to store repositories: 'C:\Users\GeoffAlexander'. If this is not correct please set the HOME environment variable and restart Eclipse. Otherwise Git for Windows and EGit might behave differently since they see different configuration options. This warning can be switched off on the Team > Git > Confirmations and Warnings preference page. ```
This warning seems unrelated, I guess the assumed home directory is correct ? Are you using OpenJ9 to run Eclipse ? Try to reproduce this issue and when the clone hangs create a couple of thread dumps for the Eclipse process. This should give us some more evidence what's going on. In order to debug the problem install the EGit developer Eclipse setup [1] and start another IDE in debug mode [2] and try your lfs scenario there again. Set a breakpoint in CloneOperation.run() and in CloneCommand.call() and look into the problem from there. [1] https://wiki.eclipse.org/EGit/Contributor_Guide#Automated_Developer_Setup [2] https://wiki.eclipse.org/EGit/Contributor_Guide#Running_EGit_from_Eclipse
Yes, the Git home directory is fine. I initially encountered this problem using IBM Java rather than OpenJ9: ``` java version "1.8.0_211" Java(TM) SE Runtime Environment (build 8.0.5.36 - pwa6480sr5fp36-20190510_01(SR5 FP36)) IBM J9 VM (build 2.9, JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled) OpenJ9 - 46e57f9 OMR - 06a046a IBM - 0b909bf) JCL - 20190409_01 based on Oracle jdk8u211-b25 ``` Based on your question about the Java version, I decided to update my IBM Java 8 to the latest version: ``` java version "1.8.0_241" Java(TM) SE Runtime Environment (build 8.0.6.6 - pwa6480sr6fp6-20200303_01(SR6 FP6)) IBM J9 VM (build 2.9, JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References 20200124_438197 (JIT enabled, AOT enabled) OpenJ9 - 6754bf2 OMR - dca2cde IBM - 5cc5f54) JCL - 20200303_01 based on Oracle jdk8u241-b07 ``` The EGit clone hang still happens. So then I decide to try the latest OpenJDK OpenJ9 8: ``` openjdk version "1.8.0_242" OpenJDK Runtime Environment (build 1.8.0_242-b08) Eclipse OpenJ9 VM (build openj9-0.18.1, JRE 1.8.0 Windows 10 amd64-64-Bit Compressed References 20200122_564 (JIT enabled, AOT enabled) OpenJ9 - 51a5857d2 OMR - 7a1b0239a JCL - 8cf8a30581 based on jdk8u242-b08) ``` The EGit clone hang also happens with the Java version. Finally, I tried the latest OpenJDK HotSpot 8: ``` openjdk version "1.8.0_242" OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_242-b08) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.242-b08, mixed mode) ``` The EGit clone hang also happens with the Java version. I'll next look at debugging Egit by setting breakpoints in CloneOperation.run() and in CloneCommand.call() as you suggest. I'll post my finding a later comment.
Can you first create a couple of thread dumps first while the clone operation hangs ?
Which JDK would you like me to use to create the thread dumps? Or does it matter?
Created attachment 282214 [details] First Java thread dump
Created attachment 282215 [details] Second Java thread dump
JGit is waiting for the external lfs smudge filter: "Worker-21: Cloning from ssh://git@github.ibm.com/zosdevtk/dbb-buildscripts" Id=108 RUNNABLE at java.lang.ProcessImpl.waitForInterruptibly(Native Method) at java.lang.ProcessImpl.waitFor(ProcessImpl.java:507) at org.eclipse.jgit.util.FS.runProcess(FS.java:1947) at org.eclipse.jgit.util.FS.execute(FS.java:2055) at org.eclipse.jgit.dircache.DirCacheCheckout.runExternalFilterCommand(DirCacheCheckout.java:1594) at org.eclipse.jgit.dircache.DirCacheCheckout.getContent(DirCacheCheckout.java:1571) at org.eclipse.jgit.dircache.DirCacheCheckout.checkoutEntry(DirCacheCheckout.java:1481) at org.eclipse.jgit.dircache.DirCacheCheckout.doCheckout(DirCacheCheckout.java:563) at org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:467) at org.eclipse.jgit.api.CloneCommand.checkout(CloneCommand.java:366) at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:202) at org.eclipse.egit.core.op.CloneOperation.run(CloneOperation.java:180) at org.eclipse.egit.ui.internal.clone.AbstractGitCloneWizard.executeCloneOperation(AbstractGitCloneWizard.java:488) at org.eclipse.egit.ui.internal.clone.AbstractGitCloneWizard.access$2(AbstractGitCloneWizard.java:481) at org.eclipse.egit.ui.internal.clone.AbstractGitCloneWizard$6.run(AbstractGitCloneWizard.java:460) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
I'm now familiar with how Git LFS works. What does it mean for JGit to be wainting for the external lfs smudge filter? How do I debug this further?
(In reply to Geoff Alexander from comment #10) > I'm now familiar with how Git LFS works. What does it mean for JGit to be > wainting for the external lfs smudge filter? How do I debug this further? I think the smudge filter implementation of the latest version is here https://github.com/git-lfs/git-lfs/blob/master/lfs/gitfilter_smudge.go I am not familiar with this code since I didn't look into lfs for a long time.
