search

dotnet / arcade

Tools that provide common build infrastructure for multiple .NET Foundation projects.
MIT License
673 stars 347 forks source link

IBC data XML output paths collide for some assemblies #2309

Closed tmat closed 5 years ago

tmat commented 5 years ago 
EXEC : error : the following exception was thrown while processing profile data [E:\A\_work\691\s\src\ExpressionEvaluator\Core\Source\ResultProvider\Portable\Microsoft.CodeAnalysis.ResultProvider.csproj]
  System.IO.IOException: The process cannot access the file 'E:\A\_work\691\s\artifacts\tmp\Release\ibcxml\Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.dll.ibc.xml' because it is being used by another process.
     at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
     at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
     at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
     at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync)
     at System.Xml.XmlWriterSettings.CreateWriter(String outputFileName)
     at IBCRead.DumpAsXml(String outFileName) in /_/src/IbcMerge/ibcmerge.cs:line 9535
     at IBCMerge.Merge(String[] args) in /_/src/IbcMerge/ibcmerge.cs:line 10871
tmat commented 5 years ago

@jaredpar FYI

jaredpar commented 5 years ago

Do you have a build link I can look at here?

Wonder how this could happen. My assumption was this isn't an issue because it would require calling ibcmerge in parallel on the same assembly. Which itself would be a bug.

tmat commented 5 years ago

I think its a different TFM of the same project.

tmat commented 5 years ago

We are embedding the same IBC data to all flavors of the assemblies built from the same project.

tmat commented 5 years ago

A quick fix would be to use a random GUID for the XML file name.

A better fix would be to use MVID of the assembly. I think we need to group the trained assemblies by their MVIDs anyways to be completely correct.

jaredpar commented 5 years ago

MVID sounds good. Could essentially emit <assembly name>-<target framework>-<mvid>.ngen.txt. Think the target framework would help a bit in debugging on occasion.

Is there a reliable way to get the MVID without loading the DLL?

jaredpar commented 5 years ago

Perfect. Already referencing SRM. Will use that for MVID.

tmat commented 5 years ago

Yes, also you can parse TFM attribute from the assembly. We already do that in signtool. you can copy that code. https://github.com/dotnet/arcade/blob/e30b95ef40d37210739019a571509632c57c9668/src/Microsoft.DotNet.SignTool/src/Configuration.cs#L394

tmat commented 5 years ago

<assembly name>-<target framework>-<mvid>.ngen.txt sounds good for the final output file. We can use Guid.NewGuid() for the temporary XML file. The name does not matter.

markwilkie commented 5 years ago

Looks like this issue might could be closed?

jaredpar commented 5 years ago

No still work to do. There were actually two bugs here:

  1. The double writes to same files during build. Most likely due to multi-tf builds.
  2. The disable logging code didn't fully disable logging.

@JoeRobich fixed the second issue. This one is still tracking the first issue.