The process cannot access the file, because it is being used by another process" error during attempt to collect coverage #1471
Comments
|
Are you refering to #1155? The fix for this wasn't released yet, but it will be in the next release. You can try out the fix by consuming our nightly build (https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/ConsumeNightlyBuild.md). |
|
Don't think he means that one, but this one: I'm facing this issue again when using coverlet.console v6.0.0 Just did some more testing with different versions of the tool: I don't have the issue using v3.1.x or v3.2.0, but I do with v6.0 With v6 I get this kind of exception: ---> System.IO.IOException: The process cannot access the file '(real path left out for nda reasons).pdb' because it is being used by another process. |
|
I just started encountering this same after installing the newly-released C# Dev Kit for VSCode. It seems the processes started by VSCode keep a handle open on the assemblies: Once I close VSCode and run |
|
This issue is stale because it has been open for 3 months with no activity. |
|
This has been a problem for my team as we have minimum code coverage being applied to changed code as a policy in pull requests. This bug is preventing us from being able to complete pull requests. I have found that with this bug in 6.0.0, we get this error in the
|
|
This issue is stale because it has been open for 3 months with no activity. |
|
Issue should be closed because the related coverlet nuget package is not mentioned and comments for all packages are available. The new issue template for bugs should improve this. |
|
This issue is stale because it has been open for 3 months with no activity. |
|
I get the same error on one of my .NET 4.8 projects. I am using the coverlet console tool as part of an Azure Pipeline. Tool version is 6.0.2 The exit code from coverlet is 255, which is undocumented. Command:
Output: (...) BadImageFormatException during MetadataReaderProvider.FromPortablePdbStream in InstrumentationHelper.PortablePdbHasLocalSource, unable to check if module has got local source. |
|
We still have this issue on 6.0.0, 6.0.1 and 6.0.2. Version 3.2.0 still works fine. |
Same here. v6.0.2 has the "because it is being used by another process." error but v3.2.0 works without issue. |
|
For me, using Coverlet 6.0.2 as a dotnet tool, it looks like it's actually the coverlet process itself, which is holding the lock. VS Code's Code.exe does indeed execute in the middle, but it's just reading file attributes. I was able to reproduce the error with no VS code open, it even occurs in our CI pipeline. Here's the stack of the WriteFile that succeeds: WriteFile, SUCCESSHere's the CreateFile (=Open a new handle) operation that fails: CreateFile, SHARING VIOLATIONHere's the error stack of the coverlet failure, matching the SHARING_VIOLATION procmon event: Error stackMy interpretation of the event stacks is that coverlet is trying to copy the file, while it still has open a previous handle, that was used to manipulate the PDB with PS: Why is coverlet editing the PDB anyway? Is it adjusting some offsets after instrumenting the executable shifted addresses around? |
|
I was able to catch coverlet.console.exe in the debugger, trying to restore the original modules, with process explorer showing it still having a handle to the PDB: Experiment done with a local debug build I made from commit c27f704 of master. Looking at the call stack, this RestoreOriginalModule invocation is coming from the exception handler in
|
The Problem: Problem observed when being used in coverlet: coverlet-coverage/coverlet#1471 If an exception caused `NativePdbWriter.Write` to never be called, it would not call `SymWriter.Close`, which in turn meant `Marshal.ReleaseComObject` was left uncalled. The garbage collector will eventually destroy the object and thereby release the COM object, but that happens non-deterministically. The COM object is holding to a file handle, which prevents other operations on the written file until it is released. The result was random file access issues. The Solution: Luckily NativePdbWriter is IDisposable. I added a call to `writer.Close` there. But now it could be called twice, so I had to add a boolean to SymWriter to avoid releasing everything twice.
|
I believe this (microsoft/testfx#2563) issue on testfx is caused by this one |
|
@tripleacoder Please check known issues BadImageFormatException .NET Framework 4.7.x, 4.8.x This issue is related to “Unable to instrument module” exception and “The process cannot access the file 'XXX.dll or XXX.pdb' because it is being used by another process.” Related external issue: Fixed: SymWriter COM object is not released on exception |
Bertk
added
tracking-external-issue
Thanks, changing DebugType to 'portable' made the error go away. |
* Fixed: SymWriter COM object is not released on exception The Problem: Problem observed when being used in coverlet: coverlet-coverage/coverlet#1471 If an exception caused `NativePdbWriter.Write` to never be called, it would not call `SymWriter.Close`, which in turn meant `Marshal.ReleaseComObject` was left uncalled. The garbage collector will eventually destroy the object and thereby release the COM object, but that happens non-deterministically. The COM object is holding to a file handle, which prevents other operations on the written file until it is released. The result was random file access issues. The Solution: Luckily NativePdbWriter is IDisposable. I added a call to `writer.Close` there. But now it could be called twice, so I had to add a boolean to SymWriter to avoid releasing everything twice. * Code style --------- Co-authored-by: Jb Evain <[email protected]>
|
Note Portable PDB - Why a new format?
|
I can see previous issue being fixed in an unofficial version - did it ever make it to stable release?
The issue still exist with running test in parallel with vstest code coverage (XPlat code coverage)
The text was updated successfully, but these errors were encountered: