помилка MSB4166: Дочірній вузол вийшов передчасно. Закриття

Іноді моя сборка збігається з цією помилкою.

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

Здається, це абсолютно випадково, і я не зміг його відтворити за власним бажанням. Я запускаю VS2010 Win7 x64 MSBuild 4.0, але ця проблема, здається, незалежна від платформи та операційної системи. Я створюю рішення паралельно (/ m switch + BuildInParallel = True), і я не хочу вимикати цю функцію, оскільки складаю додаток з 800 + проектами. Будь-яка ідея, як її вирішити?

EDIT: Коли я встановив попередній перегляд розробника .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 _ *. Fail.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,5 ГБ).
додано Автор Ludwo, джерело
Так, здається, MSBuild не використовує віртуальну пам'ять :)
додано Автор Ludwo, джерело
Але це неправда. Я перевірив це, і це не вдалося з цього питання, якщо він має 800 МБ вільної фізичної пам'яті.
додано Автор Ludwo, джерело
У мене є ті самі неприємності. Я також бачив винятки з пам'яті, пов'язані з цією помилкою. Обмеження на одне одночасне збирання не допомагає; це все одно є помилками: Перегляньте знімок екрана тут ; помилка виникає саме тоді, коли споживання пам'яті перевищує фізичну доступну пам'ять. Він мав декілька близьких щіток зі смертю, а потім вийшов на максимум і помер, знявши з ним Outlook і Process Explorer, запропонувавши відладчик JIT, який не запускається, і випустивши MSBuild.exe, щоб стати процесом зомбі, що сидить на пам'яті поки я вручну його не вб'ю.
додано Автор Kevin Vermeer, джерело
Я використовую 32-розрядний MSBuild на 32-розрядному робочому столі WinXP з 2 Гб фізичної та аналогічно необмеженої віртуальної пам'яті. Дивна справа в тому, що аварій відбувається, коли фізична пам'ять повністю вичерпана. Це схоже на нульову віртуальну пам'ять!
додано Автор Kevin Vermeer, джерело

4 Відповіді

Як говорилося в обміні коментарями на питання:

Дивно, що я використовую 64-бітну MSBuild на 64-бітному ноутбуці Win7 з 4 Гб фізичної та "необмеженої" віртуальної пам'яті. Процес MSBuild використовує близько 1 Гб оперативної пам'яті (пік 1,5 ГБ). - Людво 4 години тому

Я використовую 32-бітний MSBuild на 32-розрядному робочому столі WinXP з 2 Гб фізичної та аналогічно необмеженої віртуальної пам'яті. Дивна справа в тому, що аварій відбувається, коли фізична пам'ять повністю вичерпана. Це схоже на нульову віртуальну пам'ять! - Кевін Вермеер 3 години тому

Так, здається, MSBuild не використовує віртуальну пам'ять :) - Ludwo 2 години тому

Схоже, MSbuild не використовував віртуальну пам'ять. Я зробив кілька тестів (починаючи з купою програм), і здавалося, що нічого не використовуючи віртуальну пам'ять. Я зробив кілька пошуків, які ведуть мене перевірити

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

і з'ясувалося, що існує така настройка, яка обмежує мій розмір віртуальної пам'яті в масштабі всієї системи. Я думав, що віртуальна пам'ять буде ефективно нескінченною або, точніше, 4 ГБ для кожного процесу на 32-розрядній XP. Я не наближався до цієї межі. Однак мій обсяг віртуальної пам'яті обмежений ... 0 Мб. Не круто, хто б чи не зробив цього.

Я змінив це, щоб виділити мінімум 1024 МБ і максимум 4096 МБ віртуальної пам'яті. Я додав стовпець "Віртуальний розмір" у Process Explorer , який разом із Графік "Приймання системи" показує, що тепер я використовую більше пам'яті, ніж сума, доступна у фізичних картах пам'яті.

Це усунуло мої проблеми. На жаль, моя система постійно припиняється, коли намагається розмістити будь-яку пам'ять, але це краще, ніж аварія. Я повторно ввімкнув паралельні збирання; він розпаралелює і використовує багато процесорів, поки я залишив ОЗУ (що відповідає більшості файлів) і припиняється до 1% від використання ЦП, коли у мене більше немає оперативної пам'яті. Після завершення цих файлів швидкість відновлюється.

2
додано
Моя VM увімкнена і керована системою
додано Автор Ludwo, джерело
Це не проблема з налаштуваннями віртуальної машини. У мене 800 Мб вільної пам'яті. Тепер я перевіряю, чи це викликано 32-розрядними розширеннями чи ні ...
додано Автор Ludwo, джерело
@Ludwo - Це хороша річ, і є безліч можливих причин такого роду помилки, але ви намагалися встановити його вручну?
додано Автор Kevin Vermeer, джерело

У моєму випадку, відповідь полягала в оновленні Antlr. Очевидно, що це стосується лише того, що ви використовуєте Antlr у вашому проекті.

1
додано

Можливо, вичерпається пам'ять, що призведе до того, що один з підрядних процесів збій вийшов з ладу - чи не скінчився він, якщо ви використовуєте/m: 2, щоб обмежити його двома одночасними збірками? (припускаючи, що у вас більше 2 ядер)

Або, якщо ви можете запозичити деяку оперативну пам'ять з іншої машини або збільшити розмір свопи, це трапляється рідше, коли у вашій машині збірки встановлено більше пам'яті?

1
додано
У мене тільки 2 ядра. Моя побудова іноді збігається з винятком пам'яті. Я буду робити розслідування, і я дам тобі знати ...
додано Автор Ludwo, джерело
У мене дуже багато вільної пам'яті, і моя помилка знову. Це має бути якось пов'язано з обмеженням 32-бітної пам'яті процесу, тому що моя побудова використовує більше 2 ГБ оперативної пам'яті. Але я не бачу, як це повинно бути можливим, тому що процес мого MSBuild 64bit.
додано Автор Ludwo, джерело

Може бути, це збудований еквівалент стану перегонів?

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

Якщо ви використовуєте звичайний еталонний тег для залежності від виходу іншого проекту, який є частиною збірки (а не тег ProjectReference), ви можете отримати ситуацію, коли зазвичай проект X завершується перед проектом Y (що залежить від проекту X вихід), але іноді вони будуються одночасно, і в цьому випадку вихід X не існував би, коли Y пішов шукати його, що спричинило б невдачу. Я не можу знайти що-небудь про те, яку виду MSBuild виводить в цій ситуації (і не має легко доступного способу це протестувати саме зараз), так що це може бути не так.

Проте непослідовність у результатах (часто успішна, іноді невдала) змушує мене підозрювати, що щось подібне може бути причиною.

1
додано
Ні. У мене величезна кількість проектів у кількох рішеннях. Я використовую завдання злиття для об'єднання рішень, і я створюю одне велике рішення, перш ніж кожна збірка зможе побудувати всі проекти паралельно. У вирішенні задач злиття я перетворюю всі посилання на проектні посилання, якщо це можливо. Тому мої файли проекту оновлюються після об'єднання рішень, як описано в прикладі2 у вашій пов'язаній статті.
додано Автор Ludwo, джерело
+1 для вашого відповіді, тому що ви побічно пояснили мені, чому тільки один екземпляр MSBuild активний, тоді як інші приклади простоюють. У дискусії я знайшов посилання на цей помилка . Він фіксується у майбутньому випуску MSBuild після v4.0. Я повинен розділити мої проекти на більш дрібні частини, щоб поліпшити продуктивність msbuild :(
додано Автор Ludwo, джерело
Дякую! Так що це нормально, коли цей великий проект був складений спочатку, і всі інші залежні проекти чекали на це.
додано Автор Ludwo, джерело
@Ludwo - Якщо це допомагає, у своєму рішенні було 8 проектів, коли я знайшов і виправив цю проблему. Вони були розділені на 800 файлів і 16000 рядків коду; близько 40% цього міститься в одному проекті.
додано Автор Kevin Vermeer, джерело