Skip to content

BUG: File locking #25

Closed
Closed
@pms1969

Description

@pms1969

My coverage script does the following:

...
# Run the tests
    for testproj in $(ls tests/*.Tests -d | grep -v Integration); do 
        echo ${testproj}; 
        set +e
        time \
            dotnet test \
                --no-build \
                --no-restore \
                --filter "TestCategory!=Integration" \
                --logger:trx \
                -r ${base_dir}/.output/ \
                $testproj \
                /nowarn:NU1701,NU1603,NU1605 \
                /p:CollectCoverage=true \
                /p:CoverletOutputFormat=opencover
        cname=$(basename $testproj)
        cp ${testproj}/coverage.xml ${base_dir}/.output/$cname-coverage.xml
        set -e
    done
...

This works perfectly well for the most part, but I see the following error randomly in different parts of the output on each run:

...
Total tests: 18. Passed: 18. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 4.4549 Seconds
Results File: /tmp/build/5128ae76/.output/_161d9565-a576-4c2a-7fe5-1bb0ae8a6598_2018-04-04_12_54_05.trx

Calculating coverage result...
/tmp/build/5128ae76/source-code-core/packages/coverlet.msbuild/1.0.3-beta1/build/netstandard2.0/coverlet.msbuild.targets(19,5): error : The process cannot access the file '/tmp/build/5128ae76/source-code-core/tests/Diagnostics.Tests/bin/Debug/netcoreapp2.0/MyAssemblyDependency.dll' because it is being used by another process. [/tmp/build/5128ae76/source-code-core/tests/Diagnostics.Tests/Diagnostics.Tests.csproj]

real	0m6.404s
user	0m2.980s
sys	0m0.280s
cp: cannot stat 'tests/Diagnostics.Tests/coverage.xml': No such file or directory

Any ideas?

Cheers,
Paul

NB: coverlet-1.0.3-beta1 is a build of the current master so as to capture the change from PR #23 and hosted in a local nuget repo.

Activity

tonerdo

tonerdo commented on Apr 4, 2018

@tonerdo
Collaborator

What test framework are you using?

sampwil

sampwil commented on Apr 4, 2018

@sampwil

I have encountered the same locking issue but it is consistent. I have xUnit tests running on TeamCity version 2017.2.2. Works on my local machine without an issue after PR #23.

/root/.nuget/packages/coverlet.msbuild/1.0.3-beta/build/netstandard2.0/coverlet.msbuild.targets(19,5): error : The process cannot access the file '/opt/buildagent/work/895704bd6e7179f/src/Server.Tests/bin/Debug/netcoreapp2.1/Pie.Quote.Domain.dll' because it is being used by another process. [/opt/buildagent/work/895704bd6e7179f/src/Server.Tests/Server.Tests.csproj]

pms1969

pms1969 commented on Apr 4, 2018

@pms1969
ContributorAuthor

@tonerdo I'm using nunit.

@sampwil Interesting that it's working for you after that PR.

tonerdo

tonerdo commented on Apr 4, 2018

@tonerdo
Collaborator

@sampwil @pms1969 what operating system do you get these errors on?

sampwil

sampwil commented on Apr 4, 2018

@sampwil

My Teamcity agent setup is

root@27032d820136:/# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

FROM jetbrains/teamcity-agent

RUN curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
&& mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
&& sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-xenial-prod xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
&& apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893
&& curl -sL https://deb.nodesource.com/setup_8.x | bash -
&& apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
&& echo "deb http://download.mono-project.com/repo/ubuntu xenial main" | tee /etc/apt/sources.list.d/mono-official.list
&& apt-get update
&& apt-get --assume-yes install dotnet-sdk-2.1.300-preview1-008174 nodejs git apt-transport-https ca-certificates curl software-properties-common mono-devel fsharp
&& npm install npm --global

My local setup is
https://docs.microsoft.com/en-us/windows/wsl/install-win10

With Ubuntu 16.04 LTS

@tonerdo The error occurs on the teamcity setup and not my local setup

pms1969

pms1969 commented on Apr 5, 2018

@pms1969
ContributorAuthor

@tonerdo I'm running in a slightly modified microsoft/dotnet container. https://hub.docker.com/r/microsoft/dotnet/ 2.0-sdk. I add in a few other things like sonar-scanner, which requires java, and a bunch of tools, but it's not far off being vanilla.

tonerdo

tonerdo commented on Apr 6, 2018

@tonerdo
Collaborator

The problem is from this line: https://github.com/tonerdo/coverlet/blob/master/src/coverlet.core/Coverage.cs#L82

I restore the backup of the original uninstrumented module so that if the next run uses the --no-build flag coverlet will be dealing with the original module

pms1969

pms1969 commented on Apr 9, 2018

@pms1969
ContributorAuthor

A simple exponential retrier? I'm guessing the runtime hasn't finished unloading/garbage collecting/finalising/disposing of the module, but that is only a matter of time. It would obviously need a timeout as you don't want to wait around for some dodgy code to finish cleaning up that may never actually do so. An exponential retrier could start with a 6 milliseconds backoff with say 10 retries that's:
6 -> 12 -> 24 -> 48 -> 96 -> 192 -> 384 -> 758 -> 1536 -> 3072

If it hasn't finished inside what is just over 6 seconds then it's a bust. I'd be super surprised if just sleeping 6 milliseconds wasn't long enough for the clr to take control and finish closing the file in 98% of cases. Given that it's done without the need of a retry in a good number of cases already. I'm guessing it depends on how much disposing/finalising work is required by the code under test.

Might also be handy having a log message stating how many retries were required to complete (say with a --verbose flag).

Happy to have a stab at it if you think this is a reasonable approach.

tonerdo

tonerdo commented on Apr 9, 2018

@tonerdo
Collaborator

@pms1969 by all means take a stab at this. Let's leave out logging for now and just do everything behind the scenes.

pms1969

pms1969 commented on Apr 9, 2018

@pms1969
ContributorAuthor

@sampwil would you be able to test that PR and see if you still get the issue. Looks like it worked locally for me, but it's always hard to tell if it has actually resolved in cases like this. I'm having some unrelated other system issues as well, so confirmation from another source would be desirable.

sampwil

sampwil commented on Apr 9, 2018

@sampwil

@pms1969 Will do. I will try to put on the schedule for today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @pms1969@tonerdo@sampwil

        Issue actions

          BUG: File locking · Issue #25 · coverlet-coverage/coverlet