時々、私のエラーはこのエラーで失敗します。
0>MSBUILD : error MSB4166: Child node "3" exited prematurely. Shutting down.
完全にランダムなようで、思い通りに再現できませんでした。 VS2010 Win7 x64 MSBuild 4.0を実行していますが、この問題はプラットフォームやOSに依存しないようです。ソリューションを並行して構築しています(/ mスイッチ+ BuildInParallel = True)。800以上のプロジェクトを含むアプリケーションをコンパイルしているため、この機能を無効にしたくありません。それを解決する方法はありますか?
編集:.NET 4.5開発者プレビューをインストールすると、MSBuild 4.5でエラーログが改善され、エラー文字列は次のようになります。
error MSB4166: Child node "3" exited prematurely. Shutting down. Diagnostic information may be found in files in the temporary files directory named MSBuild_*.failure.txt
Tempフォルダーにエラーログファイルがあります。これは、MSBuild _ *。failure.txtファイルの内容です。
System.InvalidOperationException: BuildEventArgs has formatted message while serializing!
at Microsoft.Build.Framework.LazyFormattedBuildEventArgs.WriteToStream(BinaryWriter writer)
at Microsoft.Build.Framework.BuildMessageEventArgs.WriteToStream(BinaryWriter writer)
at Microsoft.Build.Shared.LogMessagePacketBase.WriteToStream(INodePacketTranslator translator)
at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.PacketPumpProc()
多くの時間とこの問題を解決しようとする研究の後、私は私のために働く解決策を見つけました。/mおよび/ p:BuildInParallel = trueを指定してmsbuildを使用していますが、CIサーバーでビルドが失敗していました。それは常に2番目のコンポーネントでエラーで失敗していました:
エラーMSB4166:子ノード「3」が途中で終了しました。シャットダウンしています。
/ nodeReuse:falseを追加すると、問題が修正されました。
これは良いリファレンスです: https://blogs.msdn.Microsoft.com/msbuild/2007/04/16/node-reuse-in-multiproc-msbuild/
質問に対するコメントの交換で議論されたように:
奇妙なことに、4 GBの物理RAMと「無制限」の仮想RAMを搭載した64ビットWin7ラップトップで64ビットMSBuildを使用しています。 MSBuildプロセスは、約1GBのRAM(1,5GBピーク)を使用しています)– Ludwo 4時間前
2GBの物理RAMと同様に無制限の仮想RAMを備えた32ビットWinXPデスクトップで32ビットMSBuildを使用しています。奇妙なことに、物理的なRAM=が完全に使い果たされるとクラッシュが発生します。仮想メモリがゼロになっているようなものです!–ケビンフェルメール3時間前
はい、MSBuildは仮想メモリを使用していないようです:) – Ludwo 2時間前
MSbuildが仮想メモリを使用していないようです。私はいくつかのテスト(たくさんのプログラムを開始する)を行い、仮想メモリをnothingが使用しているように見えました。いくつかの検索を行ったため、確認する必要がありました
Control Panel -> System -> Advanced -> Performance -> Advanced -> Virtual Memory
システム全体で仮想メモリのサイズを制限する設定が存在することがわかりました。私は、仮想メモリが32ビットXPのプロセスごとに事実上無限、つまり正確には4 GBになると想像していました。私はこの限界に近づいていませんでした。しかし、私の仮想メモリ空間は... 0MBに制限されていました。誰でも何でもそれをした人はクールではありません。
これを変更して、最小で1024 MB、最大で4096 MBの仮想メモリを割り当てます。 Process Explorer に「仮想サイズ」列を追加しました。これは、「システムコミット」グラフとともに、物理的に利用可能な量よりも多くのメモリを使用していることを示していますRAMスティック。
これで問題が解決しました。残念ながら、私のシステムはメモリをページングしようとするたびにほぼ停止しますが、クラッシュよりはましです。並列ビルドを再度有効にしました。 RAM=(ほとんどのファイルに当てはまります)残りますが、RAMがなくなったときにCPU使用率の1%に低下しますが、CPUを並列化して使用します。これらのファイルが完了すると、速度が復元されます。
私の場合、答えはAntlrを更新することでした。明らかに、これはプロジェクトでAntlrを使用している場合にのみ適用されます。
メモリが不足して、ビルドサブプロセスの1つが失敗する可能性があります-/ m:2を使用して2つの同時ビルドに制限すると、失敗が少なくなりますか? (2つ以上のコアがあると仮定)
または、別のマシンからRAM=を借りたり、スワップサイズを増やしたりできる場合、ビルドマシンにより多くのメモリがインストールされていると、それほど頻繁に発生しませんか?
おそらくそれは、レースコンディションのビルド相当ですか?
http://blogs.msdn.com/b/msbuild/archive/2007/04/26/building-projects-in-parallel.aspx
(ProjectReferenceタグではなく)ビルドの一部である別のプロジェクトの出力への依存関係に通常のReferenceタグを使用している場合、通常、プロジェクトXがプロジェクトY(プロジェクトXに依存)の前に完了するという状況になる可能性があります。出力)しかし、時々それらは同時にビルドされます。その場合、Yが探しに行ったときにXの出力が存在せず、Yが失敗しました。 MSBuildがそのような状況でどのようなエラー出力を出すかについては何も見つかりません(そして今すぐテストするための簡単に利用できる方法がありません)ので、それはそうではないかもしれません。
それでも結果の不整合(多くの場合、成功し、時々失敗する)は、そのようなことが原因である可能性があると私に疑わせます。
同じmsbuildエラーが発生し、ログファイルに
UNHANDLED EXCEPTIONS FROM PROCESS 10260:
=====================
05/01/2019 18:41:55
System.IO.IOException: Pipe is broken.
at System.IO.Pipes.PipeStream.WinIOError(Int32 errorCode)
at System.IO.Pipes.PipeStream.BeginWriteCore(Byte[] buffer, Int32 offset, Int32 count, AsyncCallback callback, Object state)
at System.IO.Pipes.PipeStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)
at System.IO.Pipes.PipeStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at Microsoft.Build.BackEnd.NodeEndpointOutOfProcBase.RunReadLoop(Stream localReadPipe, Stream localWritePipe, ConcurrentQueue`1 localPacketQueue, AutoResetEvent localPacketAvailable, AutoResetEvent localTerminatePacketPump)
===================
環境変数MSBUILDDISABLENODEREUSE=1
を設定してmsbuild-nodeの再利用機能を無効にすることで問題を解決できました。
ここで他の応答でこの問題を解決できなかった人のために私のケースと解決策を追加したかっただけです。
私にとっては、.NET Framework 4.6.1プロジェクトへのプロジェクト参照を誤って.NET Standard 2.0プロジェクトの1つに追加してしまったためです。この記事の執筆時点およびVS 2017 15.9.12では、参照にソリューションエクスプローラーに表示される「黄色の三角形」の記号として、問題が発生していることに気付くことはほとんどありません。私はいくつかのプロジェクトを含むソリューションを持っていて、ビルドソリューションの途中のどこかで、ランダムなプロジェクトでこの「子Node Xが途中で終了しました」で失敗し、どこで失敗したかは一貫していません。
問題のある.NET Framework 4.6.1参照プロジェクトに間違いを見つけたら、この.NET Framework 4.6.1プロジェクトを.NET Standard 2.0に変換しました。これらすべての子Node Xエラー立ち去った。
これが誰でも読むのに役立つことを願っています。