multithreading - error MSB4166: El nodo hijo salió prematuramente. Apagando

msbuild msbuild-4.0

Question

A veces mi compilación falla con este error.

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

Parece ser completamente aleatorio y no he podido reproducirlo a voluntad. Estoy ejecutando VS2010 Win7 x64 MSBuild 4.0 pero este problema parece ser independiente de la plataforma y del sistema operativo. Estoy creando soluciones en paralelo (/ m switch + BuildInParallel = True) y no quiero deshabilitar esta función porque estoy compilando una aplicación que contiene más de 800 proyectos. ¿Alguna idea de cómo solucionarlo?

EDITAR: Cuando instalé la vista previa del desarrollador de .NET 4.5, se mejoró el registro de errores en MSBuild 4.5 y ahora la cadena de error se ve así:

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

Puedo encontrar el archivo de registro de errores en la carpeta Temp. Este es el contenido del archivo 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()

Answer 1

Como se discutió en el intercambio de comentarios a la pregunta:

Lo extraño es que estoy usando MSBuild de 64 bits en una computadora portátil Win7 de 64 bits con 4 GB de RAM virtual "ilimitada" física. El proceso MSBuild está utilizando aproximadamente 1 GB de RAM (1,5 GB de pico). - Ludwo hace 4 horas

Estoy usando MSBuild de 32 bits en un escritorio WinXP de 32 bits con 2 GB de RAM virtual y una RAM virtual igualmente ilimitada. Lo extraño es que el bloqueo se produce cuando la memoria RAM física está completamente agotada. Es como si no tuviera memoria virtual! - Kevin Vermeer hace 3 horas.

Sí, parece que MSBuild no usa memoria virtual :) - Ludwo hace 2 horas

Parecía que MSbuild no estaba usando la memoria virtual. Hice algunas pruebas (iniciando un montón de programas) y parecía que nada estaba usando memoria virtual. Hice algunas búsquedas que me llevaron a comprobar

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

y descubrió que existe una configuración que limita el tamaño de mi memoria virtual en todo el sistema. Me había imaginado que la memoria virtual sería infinitamente efectiva o, más precisamente, 4 GB para cada proceso en XP de 32 bits. No me estaba acercando a este límite. Sin embargo, mi espacio de memoria virtual estaba limitado a ... 0MB. No está bien, quien sea o lo que haya hecho eso.

Cambié esto para asignar un mínimo de 1024 MB y un máximo de 4096 MB de memoria virtual. Agregué la columna "Tamaño virtual" en Process Explorer , que, junto con el gráfico "Compromiso del sistema", demuestra que ahora uso más memoria que la cantidad disponible en las memorias RAM físicas.

Esto solucionó mis problemas. Desafortunadamente, mi sistema se detiene casi por completo cada vez que trata de buscar alguna memoria, pero eso es mejor que un fallo. Volví a habilitar las construcciones paralelas; se paraliza y usa mucha CPU mientras que me queda RAM (lo cual es cierto para la mayoría de los archivos) y baja al 1% del uso de la CPU cuando no tengo más RAM. Cuando se hacen esos archivos, se restaura la velocidad.

Answer 2

En mi caso, la respuesta fue actualizar Antlr. Obviamente, esto solo se aplica si está utilizando Antlr en su proyecto.

Answer 3

Es posible que se esté quedando sin memoria y que uno de los subprocesos de compilación falle. ¿Falla menos si usa / m: 2 para restringirlo a dos compilaciones simultáneas? (asumiendo que tiene más de 2 núcleos)

O, si puede pedir prestada RAM de otra máquina o aumentar el tamaño de su intercambio, ¿sucede con menos frecuencia cuando tiene más memoria instalada en su máquina de compilación?

Answer 4

Tal vez es el equivalente de construcción de una condición de carrera?

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

Si está utilizando una etiqueta de referencia ordinaria para una dependencia de la salida de otro proyecto que forma parte de la compilación (en lugar de una etiqueta ProjectReference), podría obtener una situación en la que generalmente el proyecto X se completa antes que el proyecto Y (que depende de los proyectos X) salida) pero ocasionalmente se construyen de forma concurrente, en cuyo caso la salida de X no existiría cuando Y fue a buscarla, lo que provocó que Y fallara. Sin embargo, no puedo encontrar nada sobre qué tipo de salida de error da MSBuild en esa situación (y no hay una forma disponible para probarlo ahora), por lo que puede que no sea así.

Aún así, la inconsistencia en los resultados (a menudo exitosa, a veces falla) me lleva a sospechar que algo así puede ser la causa.