1.8 source: unit-test failure on LockFileManagerTests

Topics: Core
Apr 9, 2014 at 1:43 PM
Edited Apr 9, 2014 at 3:21 PM
Hi,

After successfully build the 1.8 source in Visual Studio and install Orchard locally, I'm trying to build the 1.8 sources with the build-script ( ClickToBuild.cmd ) but it fails on the LockFileManagerTest. Edit: 1.7.3 builds fine.

The 1.8 build fails with:
Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.PlayWithAcquire(): Unhandled Exception: NUnit.Framework.AssertionException: Expected: 1 But was: 2

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.PlayWithAcquire(): Unhandled Exception: NUnit.Framework.AssertionException: Expected: 1 But was: 3
Then nunit-console.exe stops responding and windows asks me to close or debug the program. When I close the program the build script continues and gives in a red font a build error:

..\Orchard.proj(145,5): error MSB6006: "nunit-console" exited with code -532462766.


Running the unit tests ( starting nunit.exe in \lib\nunit\nunit.exe and opening the Orchard.Framework.Tests.dll to run the Orchard\Tests\FileSystems\LockFile\LockFileManagerTests tests), gives me 7 failed tests (out of 9)

Only the ExpiredLockShouldBeAvailable and ShouldGrantExpiredLock tests are passing.

These log entries are given by NUnit:
Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  2

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  3

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  4

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  5

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 0 But was:  4

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  5

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  6

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  7

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  8

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  9

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.AcquiringLockShouldBeThreadSafe:
  Expected: 0 But was:  9

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.DisposingLockShouldReleaseIt:
  Expected: True But was:  False

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.ExistingLockFileShouldPreventGrants:
  Expected: False But was:  True

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  10

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  11

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  12

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  13

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  14

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  15

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  16

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  17

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  18

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
An unhandled NUnit.Framework.AssertionException was thrown while executing this test :   Expected: 1 But was:  19

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.IsLockedShouldBeThreadSafe:
  Expected: 0 But was:  19

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.LockShouldBeGrantedWhenDoesNotExist:
  Expected: True But was:  False

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.ReleasingALockShouldAllowGranting:
  Expected: True But was:  False

Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.ReleasingAReleasedLockShouldWork:
  Expected: True But was:  False
When performing the same unit tests with the 1.7.2 sourcecode the LockFileManagerTest are all passing. Accordingly, running the build script runs fine as well.

Has it something to do with the changes in DefaultLockFileManager.cs ( added CultureInfo in the TryAcquireLock method?

Or perhaps with the update to .net 4.5?

Local threading issue?

Does anyone have any clues to solve this? Thank you in advance.
Coordinator
Apr 9, 2014 at 5:14 PM
I don't see it on my local machine, but it happened a few times on the CI server.
Apr 10, 2014 at 6:40 AM
Edited Apr 10, 2014 at 6:46 AM
What is the "CI" server and how did you fix it? :P

It prevents me from pushing updates to the production environment


edit: found it, Continuous-Integration server.

For what it's worth this is my setup:

VMWare virtual machine
  • 2 procs with 1 core ( usually I do 1 proc with 2 cores, I don't know why it misconfigured this one; but then again the build works fine in 1.7.2 and 1.7.3
  • Windows 7 32 bit
  • VS 2013 update 1, all product updates
  • anything else worth mentioning?
Apr 10, 2014 at 7:20 AM
Found it.

Reverting the changes made in DefaultLockFileManager.cs 'fix' these test faillures:

Line 30:

reverting:
lockFile = new LockFile(_appDataFolder, path, _clock.UtcNow.ToString(CultureInfo.InvariantCulture), _rwLock);
in the TryAcquireLock-method to
lockFile = new LockFile(_appDataFolder, path, _clock.UtcNow.ToString(), _rwLock);
and removing the using of the "System.Globalization" namespace, fixes the build faillures. I don't understand why yet though.
Coordinator
Apr 10, 2014 at 5:41 PM
Maybe there is some discrepancy between two .ToString() calls ...
Apr 25, 2014 at 2:49 PM
The problem seems simply to be in the following method:
private bool IsLockedImpl(string path) {
    if (_appDataFolder.FileExists(path)) {
        var content = _appDataFolder.ReadFile(path);

        DateTime creationUtc;
        if (DateTime.TryParse(content, out creationUtc)) {
            // if expired the file is not removed
            // it should be automatically as there is a finalizer in LockFile
            // or the next taker can do it, unless it also fails, again
            return creationUtc.Add(Expiration) > _clock.UtcNow;
        }
    }

    return false;
}
The TryParse fails if the date is not parsable on system with a different culture from InvariantCulture... of course the failure is only when the InvariantCulture resulting date (mm/dd/yyyy) has a day bigger than 12 (which is probably why they were not always failing in CI?).

This should fix it:
if (DateTime.TryParse(content, CultureInfo.InvariantCulture, DateTimeStyles.None, out creationUtc)) {
At least it fixes stuff on my machine and my CI server :)
Apr 25, 2014 at 7:01 PM
Confirmed! This fixes all the failing unit tests.

Although it also failed when the day was less than 12. I'm in the Netherlands with the appropriate culture.

Tnx!
Jun 18, 2014 at 9:18 PM
Same here!

I had this problem with Orchard 1.8 and I'm located in Belgium.

The code by Tallmaris fixes the failing unit test!
Coordinator
Jun 18, 2014 at 10:45 PM
Thanks, the issue was fixed a long time ago and should actually be in 1.8.1, you might want to try it now. It's available in the downloads section.
Jun 19, 2014 at 9:35 AM
Sorry, I should have checked the 1.x branch...
Coordinator
Jun 19, 2014 at 5:15 PM
1.x is more advanced than 1.8.x. The fix is available in both.
Jun 20, 2014 at 12:38 PM
I believe it's not. I checked 1.8.1 RC and 1.x and the fix as described by Tallmaris in DefaultLockFileManager.cs is not present, in both sources. IsLockedImpl is still using the wrong? overload of DateTime.TryParse.

I could have missed it but I also didn't see it come through in the Git commits.

Or did sebastien fixed it somewhere else? The result is the same: the build fails at the unit test. With the fix applied to the 1.8.1 RC source, the build succeeds.
Coordinator
Jun 20, 2014 at 7:29 PM
I just fixed it in 1.8.x. Will be part of a 1.8.1 RC2 today.
Jun 23, 2014 at 8:18 AM
Tried 1.8.1 RC2 but still fails.

It's the:
ExpiredLockShouldBeAvailable test:
"Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.ExpiredLockShouldBeAvailable: Expected: False But was: True"

and the ShouldGrantExpiredLock test:
"Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.ShouldGrantExpiredLock: Expected: True But was: False"

The discrepancy is in the DateTimeStyles parameter: DateTimeStyles.AssumeUniversal instead of DateTimeStyles.None?
Jul 1, 2014 at 1:55 PM
I can confirm that the freshly downloaded 1.8.1 RC2 will not compile using ClickToBuild.cmd. I have applied Tallmaris' fix manually and ist worked.
Jan 15, 2015 at 6:32 PM
vulcanvulcan wrote:
Tried 1.8.1 RC2 but still fails.

It's the:
ExpiredLockShouldBeAvailable test:
"Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.ExpiredLockShouldBeAvailable: Expected: False But was: True"

and the ShouldGrantExpiredLock test:
"Orchard.Tests.FileSystems.LockFile.LockFileManagerTests.ShouldGrantExpiredLock: Expected: True But was: False"

The discrepancy is in the DateTimeStyles parameter: DateTimeStyles.AssumeUniversal instead of DateTimeStyles.None?
Using Orchard 1.8.1, which already had: DateTimeStyles.AssumeUniversal in there, I received errors when trying to run the ClickToBuild.cmd file. The error was:
"nunit-console.exe" exited with code 532462766
After going into DefaultLockFileManager.cs and changing DateTimeStyles.AssumeUniversal to DateTimeStyles.None the error went away and the build was successful.
Feb 20, 2015 at 3:34 PM
Edited Feb 20, 2015 at 3:54 PM
I can confirm that 1.8.1 still isn't fixed. I am located in Croatia. Tried changing to US/ENG locale in my windows, still not working (but without restarting the PC, just restarting the ClickToBuild).

EDIT
Same as hvaughan3, AsseUniversal was there, but still didn't work.


When changed to None, now I get 19 errors... why is it so impossible to build 1.8.1 ? :(