NGit library hangs at application shutdown (_object_87::~_object_87 never called)

[sehe]

BatchingProgressMonitor's alarmQueue is preventing application exit with NGit.

The destructor of _object_87 is never called, causing the thread pool (alarmQueue in BatchingProgressMonitor) to hang indefinitely.

I have proof-of-concepted a workaround based on calling alarmQueue.ShutdownNow() explicitely, see here

http://stackoverflow.com/questions/6310691/some-ngit-stuff-prevents-c-application-from-shutting-down-correctly/6311193#6311193

Minimal failing example:

using System;
using NGit;
using NGit.Api;
using NGit.Transport;

namespace Stacko
{
    class MainClass
    {
        public static void Main (string[] args)
        {
            Git myrepo = Git.Init().SetDirectory(@"/tmp/myrepo.git").SetBare(true).Call();
            {
                var fetchResult = myrepo.Fetch()
                    .SetProgressMonitor(new TextProgressMonitor())
                    .SetRemote(@"/tmp/initial")
                    .SetRefSpecs(new RefSpec("refs/heads/master:refs/heads/master"))
                    .Call();
                //
                // Some other work...
                //
                myrepo.GetRepository().Close();
            }
            System.GC.Collect();

#if false
            System.Console.WriteLine("Killing");
            BatchingProgressMonitor.ShutdownNow();
#endif
            System.Console.WriteLine("Done");

        }
    }
}

using the helper in BatchingProgressMonitor:

public static void ShutdownNow()
{
    alarmQueue.ShutdownNow();
}

Tested platforms:

1. Linux (Mono 2.6.7, .NET 3.5)
2. Linux (Mono 2.11, .NET 4.0)

[WilbertOnGithub]

I have the same problem when trying to use NGit on Windows. Calling the library results in my test application not exiting.

Basically when I use the API to try to clone a local git repository, the cloning works fine. However, the application never exits. In the current state NGit is not usable to build Git clients.

[alanmcgovern]

These issues have been fixed as far as I can tell. You shouldn't need to explicitly shut down the threads anymore. Please re-open the issue if you can reproduce hangs/deadlocks with the latest translated code.

[WilbertOnGithub]

After compiling the latest version of NGit from source, I could no longer reproduce the issue of the hanging threads. Looks fine to me.

[alanmcgovern]

Great, thanks for confirming that!

[damianh]

Hi Alan, has the ngit nuget package been updated with this fix? Asking because I just experienced this issue.

Edit: looks like it hasn't. Can it be updated?

[alanmcgovern]

I don't know who handles the nuget package. They'd need to be pinged to do a new release with all the fixes.

[damianh]

@xpaulbettsx The NGit nuget package is well out of date, can you updated it pls? Thx.

@alanmcgovern Any interest in taking over the nuget package ownership? I can do a PR with the nuspec bits, if @xpaulbettx will add you as package co-owner.

[alanmcgovern]

@damianh, i don't know much about the packaging side of nuget, but if it's not too complicated I don't mind keeping it updated.

[damianh]

Yeah, it's dead simple - a .nuspec file and an command line exe to create the package and upload to nuget.org.

Thx for the port too ;)