search

mono / ngit

Automated jgit port to c#
261 stars 152 forks source link

Sharpen.FilePath.Delete() failing randomly in NGit.Test tests #33

Open dprothero opened 12 years ago

dprothero commented 12 years ago

I successfully compiled in Visual Studio 2010, Windows 7 x64, .NET 4.0.

Trying to run all the tests in the NGit.Test project, I randomly get an IOException when trying to delete a temporary file. Here's an example:

***\ NGit.Api.CheckoutCommandTest.TestCheckoutWithNonDeletedFiles System.IO.IOException: The process cannot access the file 'C:\Users\dprothero\Documents\GitHub\ngit\bin\target\trash\test1341438627296_62\temp' because it is being used by another process. at Sharpen.FilePath.Delete() in C:\Users\dprothero\Documents\GitHub\ngit\Sharpen\Sharpen\FilePath.cs:line 148 System.IO.IOException: The process cannot access the file 'C:\Users\dprothero\Documents\GitHub\ngit\bin\target\trash\test1341438627296_62\Test.txt' because it is being used by another process. at Sharpen.FilePath.Delete() in C:\Users\dprothero\Documents\GitHub\ngit\Sharpen\Sharpen\FilePath.cs:line 148

I can re-run the test and it'll pass, but another one will fail.

David

alanmcgovern commented 12 years ago

This is more than likely because the [Setup] and [Teardown] methods are not correctly setting up/cleaning up when each individual [Test] method is run. If you run tests individually then you won't hit this error as all open files will be closed when the test finishes.

If you can figure out which resources are not being disposed that'd be great. Linux and MacOS do not have this issue as the files are not 'locked' so can still be deleted.

dprothero commented 12 years ago

Well, I've verified the Setup and Teardown have the right cleanup code in them. In fact, it's the call to RecursiveDelete(TestId(), trash, false, true); in the TearDown method LocalDiskRepositoryTestCase, which is what a lot of the tests inherit from, that is throwing the error.

So, the teardown is failing to remove the trash folder because the operations that ran within the test actually are leaving the files open. I'm not sure where to begin to investigate that.

I noticed some comments about trying to call GC.Collect() to force files to close, but that's not any guarantee that your objects will be disposed of at any predictable time. The general best practice is to avoid calling GC.Collect(), but perhaps in Java it's more common (I'm not a Java programmer).

Not sure if I have the time to invest into what it would take to squash this one.

alanmcgovern commented 12 years ago

That's my feeling too. The tests are currently running on our build machines and are green there. However if they start failing I'll definitely look into getting this fixed properly.

dprothero commented 12 years ago

Your build machines not being Windows, I assume?

dprothero commented 12 years ago

Could this be at all related to issue #34? If it is using the Posix library on Windows?

alanmcgovern commented 12 years ago

We have Windows, MacOS and Linux machines all compiling and running the tests, but on Windows I think we are running them from a cygwin environment. JGit detects this scenario and uses different codepaths as compared to a plain windows environment. I suspect this is the case as I encountered a blocking bug when running the tests normally on Windows which I fixed with commit efc6de2b7b7d6e0.

I've asked internally about how we run the tests and if we are running them under cygin, I'm going to get another build lane set up which runs them normally.

alanmcgovern commented 12 years ago

Are these tests still randomly failing with the latest code in git?

dprothero commented 12 years ago

Yes