error MSB4166: nodo hijo salió prematuramente. Apagar

A veces mi compilación falla con este error.error MSB4166: nodo hijo salió prematuramente. Apagar

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 plataforma y sistema operativo. Estoy creando soluciones en paralelo (/ m switch + BuildInParallel = True) y no quiero deshabilitar esta función porque estoy compilando aplicaciones que contienen más de 800 proyectos. ¿Alguna idea de cómo solucionarlo?

EDIT: Cuando he instalado .NET 4.5 vista previa para desarrolladores, el registro de errores se ha mejorado en el MSBuild 4.5 y ahora la cadena de error es el siguiente:

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()

Fuente

2011-10-27 Ludwo

Estoy teniendo los mismos problemas. También he visto excepciones de falta de memoria relacionadas con este error. Restringirlo a una compilación simultánea no ayuda; todavía se equivoca: [Vea la captura de pantalla aquí] (http://i.stack.imgur.com/FSyuG.png); el error ocurre precisamente cuando el consumo de memoria excede la memoria física disponible. Tuvo unos pocos pinceles con la muerte y luego alcanzó el máximo y murió, eliminando Outlook y Process Explorer con él, ofreciendo un depurador JIT que no se iniciará, y liberando MSBuild.exe para convertirse en un proceso zombie sentado en la memoria hasta que lo mate manualmente –

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" y física. El proceso de MSBuild utiliza aproximadamente 1 GB de RAM (pico de 1,5 GB). – Ludwo

Estoy usando MSBuild de 32 bits en un escritorio WinXP de 32 bits con 2 GB de RAM virtual similar y físicamente ilimitada. Lo extraño es que el bloqueo ocurre cuando la RAM física está completamente agotada. ¡Es como si no tuviera memoria virtual cero! –

Usted podría estar quedándose sin memoria, haciendo que uno de los procesos de acumulación de fallar sub - hace fracasar menos si usa/m: 2 para restringir a dos compilaciones concurrentes? (suponiendo que tiene más de 2 núcleos)

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

Fuente

2011-10-31 07:22:35

Tengo solo 2 núcleos. Mi compilación a veces falla en la excepción de falta de memoria. Investigaré un poco y te avisaré ... – Ludwo

Tengo mucha memoria libre y he fallado de nuevo. Debería estar de alguna manera relacionado con la limitación de la memoria del proceso de 32 bits porque mi compilación está utilizando más de 2 GB de RAM. Pero no veo cómo debería ser posible porque mi proceso de MSBuild es de 64 bits. – Ludwo

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

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

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

Sí, parece que MSBuild no está utilizando la memoria virtual :) - Ludwo hace 2 horas

Lo que parece como MSBUILD no estaba usando virtuales memoria. Hice algunas pruebas (comenzando un montón de programas) y me pareció que nada estaba usando memoria virtual. Hice algunas búsquedas que me llevan a comprobar

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

y se encontró que existe un ajuste que limita mi virtual de todo el sistema de tamaño de la memoria. Me imaginaba que la memoria virtual era efectivamente infinita, o más precisamente, 4 GB para cada proceso en 32 bits XP. No me estaba acercando a este límite. Sin embargo, mi espacio de memoria virtual estaba limitado a ... 0MB. No es genial, quien sea o lo que sea que hizo 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 "Comprometer el sistema", demuestra que ahora uso más memoria que la cantidad disponible en las barras de RAM físicas.

Esto solucionó mis problemas. Desafortunadamente, mi sistema casi se detiene cuando intenta buscar cualquier memoria, pero eso es mejor que un bloqueo. Rehabilité las construcciones paralelas; se paraleliza y usa mucha CPU mientras tengo memoria 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 memoria RAM. Cuando esos archivos están listos, se restablece la velocidad.

Fuente

2011-11-02 14:56:53

Mi VM está habilitada y administrada por el sistema – Ludwo

@Ludwo - Eso es algo bueno, y sin duda hay muchas causas posibles para este tipo de error, pero ¿ha intentado configurarlo manualmente? –

No es un problema de configuración de VM. Tengo 800 MB de memoria libre. Ahora verificaré si es causado por extensiones de 32 bits o no ... – Ludwo

¿Quizás es el equivalente 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 común para una dependencia de la salida de otro proyecto que forma parte de la construcción (en lugar de una etiqueta ProjectReference) que podría obtener una situación en la que se completa por lo general el proyecto X antes del proyecto Y (que depende de la salida del proyecto X), pero ocasionalmente se crean al mismo tiempo, en cuyo caso la salida de X no existiría cuando Y fuera a buscarlo, provocando que Y fallara. Sin embargo, no puedo encontrar nada acerca del tipo de salida de error que proporciona MSBuild en esa situación (y no tengo una forma fácilmente disponible para probarlo en este momento), así que puede que no sea así.

Todavía la inconsistencia en los resultados (a menudo exitosa, ocasionalmente falla) me lleva a sospechar que algo así puede ser la causa.

Fuente

2011-11-05 04:47:41 MikeBMcL

No. Tengo una gran cantidad de proyectos en múltiples soluciones. Utilizo mi tarea de combinación para fusionar soluciones y creo una gran solución antes de cada compilación para poder construir todos los proyectos en paralelo. En la tarea de fusión de soluciones, convertiré todas las referencias en referencias de proyecto si es posible. Así que mis archivos de proyecto se actualizan luego de que las soluciones se fusionen como se describe en el ejemplo 2 en su artículo vinculado. – Ludwo

+1 por su respuesta porque indirectamente me explicó por qué solo una instancia de MSBuild está activa mientras que otras instancias están inactivas. En la discusión, encontré un enlace a [este error] (https://connect.microsoft.com/VisualStudio/feedback/details/635800/msbuild-exe-aparece-para-colgar-cuando-maxcpucount-es-usado-y-un-gran-número-de-proyecto-referencias-existe # detalles). Se corrigió en la futura versión de MSBuild después de v4.0. Tengo que dividir mis proyectos en partes más pequeñas para mejorar el rendimiento de msbuild :( – Ludwo

@Ludwo - Si me ayuda, tuve 8 proyectos en mi solución cuando encontré y solucioné este problema. Se dividieron en unos 800 archivos y 16,000 líneas de código. ; aproximadamente el 40% de esto se incluyó en un proyecto. –

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

Fuente

2017-07-30 02:18:01

error MSB4166: nodo hijo salió prematuramente. Apagar

Respuesta

Cuestiones relacionadas