Памылка MSB4166: даччыны вузел выйшаў заўчасна. выключэнне

Часам мая зборка пацерпіць няўдачу з гэтай памылкай.

 0>MSBUILD : error MSB4166: Child node "3" exited prematurely. Shutting down.

Здавалася б, зусім выпадкова, і я не быў у стане прайграць яго па сваім жаданні. Я бег VS2010 Win7 x64 MSBuild 4.0, але гэтая праблема, як уяўляецца, платформа і незалежная ад АС. Я будую рашэння паралельна (/ м перамыкач + BuildInParallel = True), і я не хачу, каб адключыць гэтую функцыю, таму што я кампіляцыі прыкладання, які змяшчае 800 + праекты. Любая ідэя, як вырашыць гэтую праблему?

EDIT: Калі я ўсталяваў .NET 4.5 Developer Preview, пратакаляванне памылак было палепшана ў 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()
19
Дзіўна тое, што я выкарыстоўваю 64-бітную MSBuild на 64-бітнай Win7 ноўтбук з 4 Гб фізічнай і «неабмежаваны» віртуальнай памяці. MSBuild працэс выкарыстоўвае каля 1 ГБ аператыўнай памяці (1,5GB пік).
дададзена аўтар Ludwo, крыніца
Так, падобна, MSBuild не выкарыстоўвае віртуальную памяць :)
дададзена аўтар Ludwo, крыніца
Але гэта не так. Я праверыў яго і ён не па гэтым пытанні, калі ён мае 800MB свабоднай фізічнай памяці, даступнай.
дададзена аўтар Ludwo, крыніца
У мяне тыя ж праблемы. Я таксама бачыў, па-за з памяці выключэння, звязанага з гэтай памылкай. Абмяжоўваючы яго да адной адначасовай зборцы не дапамагае; яна па-ранейшаму памылкі па-за: Глядзіце скрыншот тут ; памылка ўзнікае менавіта тады, калі спажыванне памяці перавышае фізічны аб'ём даступнай памяці. Гэта было некалькі блізкіх шчотак са смерцю, а затым ён ударыў максімум і памёр, прымаючы светапоглядныя і Process Explorer з ім, прапаноўваючы ўверх JIT адладчык, які не запусціцца, і выпусьціўшы MSBuild.exe стаць працэс зомбі, седзячы на ​​памяць пакуль я ўручную не забіць яго.
дададзена аўтар Kevin Vermeer, крыніца
Я выкарыстоўваю 32-бітны MSBuild на 32-бітную WinXP працоўнага стала з 2 ГБ фізічнай і гэтак жа неабмежаванай віртуальнай памяці. Дзіўна тое, што адбываецца збой пры фізічнай памяці цалкам выдаткаваны. Гэта як у мяне нулявы віртуальнай памяці!
дададзена аўтар Kevin Vermeer, крыніца

4 адказы

Як ужо гаварылася ў абмене заўваг на пытанне:

<�Р> Дзіўна тое, што я выкарыстоўваю 64-бітную MSBuild на 64-бітнай Win7 ноўтбук з 4 Гб фізічнай і «неабмежаваны» віртуальнай памяці. MSBuild працэс выкарыстоўвае каля 1 ГБ аператыўнай памяці (1,5GB пік). - Ludwo 4 гадзіны назад
<�Р> Я выкарыстоўваю 32bit MSBuild на 32-бітнай WinXP працоўны стол з 2 ГБ фізічнай і гэтак жа неабмежаванай віртуальнай памяці. Дзіўна тое, што адбываецца збой пры фізічнай памяці цалкам выдаткаваны. Гэта як у мяне нулявы віртуальнай памяці! - Кевін Vermeer 3 гадзіны назад
<�Р> Так, падобна, MSBuild не выкарыстоўвае віртуальную памяць :) - Ludwo 2 гадзіны назад

Гэта, здавалася, як MSBuild не выкарыстоўвае віртуальную памяць. Я зрабіў некалькі тэстаў (пачынаючы з кучай праграм), і здавалася, што нічога не выкарыстоўваючы віртуальную памяць. Я зрабіў некаторыя пошукі, якія прыводзяць мяне праверыць

Control Panel -> System -> Advanced -> Performance -> Advanced -> Virtual Memory

і выявіў, што існуе ўстаноўку, якая абмежавала шырокую сістэму-моя віртуальнага памеру памяці. Я меркаваў, што віртуальная памяць, каб быць эфектыўна бясконцай, ці, дакладней, 4 ГБ для кожнага працэсу на 32-бітнай XP. Я не набліжаўся гэту мяжу. Тым не менш, маё віртуальную прастору памяці было абмежавана ... 0MB. Не крута, хто або што-то зрабіў.

Я змяніў гэта вылучыць як мінімум 1024 МБ і максімум 4096 МБ віртуальнай памяці. Я дадаў калонку «віртуальны памер» у Process Explorer , які разам з «сістэма фіксацыі» графік, паказвае, што я цяпер выкарыстоўваць больш памяці, чым колькасць наяўнага ў фізічных палках RAM.

Гэта фіксаванае мае праблемы. На жаль, мая сістэма перамолвае да бліжэйшай прыпынку, калі яна спрабуе старонкі любой памяці, але гэта лепш, чым аварыі. Я зноў ўключыць паралельна будуе; ён параллелизует і выкарыстоўвае шмат рэсурсаў працэсара ў той час як у мяне ёсць RAM засталася (што дакладна для большасці файлаў) і спад да 1% загрузкі працэсара, калі ў мяне няма больш аператыўнай памяці. Калі гэтыя файлы зробленыя, хуткасць аднаўляецца.

2
дададзена
Мая VM ўключана і кіруецца сістэмай
дададзена аўтар Ludwo, крыніца
Гэта не VM пытанне налады. У мяне ёсць дыскі ёмістасцю 800 МБ вольнай памяці. Цяпер я буду правяраць, калі гэта выклікана пашырэннямі 32-бітных або няма ...
дададзена аўтар Ludwo, крыніца
@Ludwo - Гэта добрая рэч, і ёсць, вядома, шмат магчымых прычын такога роду памылкі, але вы спрабавалі ўсталяваць яго ўручную?
дададзена аўтар Kevin Vermeer, крыніца

У маім выпадку, адказ павінен быў абнавіць Antlr. Відавочна, што гэта ставіцца толькі калі вы карыстаецеся Antlr ў праекце.

1
дададзена

Вы маглі б быць запушчаныя з памяці, у выніку чаго адзін з зборкі суб-працэсаў на правал - гэта правал менш, калі вы карыстаецеся/м: 2, каб абмежаваць яго два паралельных зборак? (Калі ў вас ёсць больш чым 2 ядра)

Ці, калі вы можаце пазычыць RAM ад іншай машыны, або павялічыць памер падпампоўкі, гэта адбываецца радзей, калі ў вас усталяваны больш памяці на вашай машыне пабудовы?

1
дададзена
У мяне ёсць толькі два ядра. Мая зборка часам не на што з выключэння памяці. Я буду рабіць некаторыя даследаванні, і я дам вам ведаць ...
дададзена аўтар Ludwo, крыніца
У мяне ёсць шмат вольнай памяці і маё не ўдалося зноў. Гэта павінна быць як-то звязана з абмежаваннем памяці працэсу 32bit, таму што мая зборка выкарыстоўвае больш за 2 Гб аператыўнай памяці. Але я не бачу, як гэта павінна быць магчыма, таму што мой працэс MSBuild з'яўляецца 64-бітным.
дададзена аўтар Ludwo, крыніца

Можа быць, гэта убудаваны эквівалент стану гонкі?

http://blogs.msdn.com/b/msbuild/archive/2007/04/26/building-projects-in-parallel.aspx

Калі вы карыстаецеся звычайны тэг спасылкі на залежнасць ад выйсця іншага праекта, які з'яўляецца часткай зборкі (а не ProjectReference тэга), вы маглі б атрымаць сітуацыю, калі, як правіла, праект X завяршаецца да праекта Y (які залежыць ад праекту крыжыкаў выхад), але часам яны будуюць адначасова, і ў гэтым выпадку выхад X не будзе існаваць, калі Y пайшоў шукаць яго, у выніку чаго Y на правал. Я не магу знайсці нічога пра тое, якіх памылках вываду MSBuild дае ў гэтай сітуацыі, хоць (і не Лёгкадаступны спосаб праверыць гэта прама цяпер), так што не можа быць.

Тым не менш непасьлядоўнасьць у рашэннях (часта паспяхова, часам не можа) прымушае мяне падазраваць, што нешта падобнае, што цалкам можа быць прычынай.

1
дададзена
Не. У мяне ёсць велізарная колькасць праектаў у некалькіх рашэннях. Я выкарыстоўваю сваю задачу зліцця для аб'яднання рашэнняў і стварыць адно вялікае рашэнне перад кожным будаваць, каб мець магчымасць будаваць усе праекты паралельна. У задачы зліцця рашэнняў Я пераўтварэнне ўсіх спасылак ў спасылкі праекта, калі гэта магчыма. Так што мае файлы праекта будуць абноўлены пасля рашэння зліваюцца, як апісана ў example2 ў звязаным артыкуле.
дададзена аўтар Ludwo, крыніца
+1 за ваш адказ, таму што вы ўскосна патлумачыў мне, чаму толькі адзін асобнік MSBuild актыўны ў той час як іншыя выпадкі прастойваюць. У ходзе абмеркавання я знайшоў спасылку на гэта памылка . Яна фіксуецца ў будучых версіях MSBuild пасля v4.0. Я павінен падзяліць свае праекты на больш дробныя часткі, каб палепшыць прадукцыйнасць MSBuild :(
дададзена аўтар Ludwo, крыніца
Дзякуй! Так што гэта нармальна, калі гэты вялікі праект быў складзены першы і ўсе іншыя залежныя праекты чакалі гэтага.
дададзена аўтар Ludwo, крыніца
@Ludwo - Калі гэта дапаможа, у мяне было 8 праектаў у маім рашэнні, калі я знайшоў і ліквідаваў гэтую праблему. Яны былі падзеленыя на некалькі файлаў 800 і 16000 радкоў кода; каля 40% гэтага змяшчаецца ў адным праекце.
дададзена аўтар Kevin Vermeer, крыніца