fout MSB4166: kindknoop is te vroeg verlaten. Afsluiten

Question

fout MSB4166: kindknoop is te vroeg verlaten. Afsluiten

Soms faalt mijn build met deze fout.

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

Het lijkt volkomen willekeurig en ik heb het niet naar wens kunnen reproduceren. Ik gebruik VS2010 Win7 x64 MSBuild 4.0, maar dit probleem lijkt platform- en besturingssysteemonafhankelijk te zijn. Ik bouw oplossingen parallel (/ m switch + BuildInParallel = True) en ik wil deze functie niet uitschakelen omdat ik een applicatie compileer met 800+ projecten. Enig idee hoe het op te lossen?

EDIT: Toen ik .NET 4.5 developer preview installeerde, was foutregistratie verbeterd in MSBuild 4.5 en nu ziet de foutstring er als volgt uit:

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

Ik kan het foutlogbestand vinden in de map Temp. Dit is de inhoud van het bestand 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

toegevoegd 27 oktober 2011 op 01:37 de auteur Ludwo bewerkt 14 november 2011 op 01:58

Bekeken: 38

de bron

Vreemd is dat ik 64bit MSBuild gebruik op een 64-bits Win7-laptop met 4 GB fysiek en "onbeperkt" virtueel RAM. MSBuild-proces gebruikt ongeveer 1 GB RAM (piek van 1,5 GB).

toegevoegd 02 november 2011 op 09:43, de auteur Ludwo, de bron

Ja, het lijkt erop dat MSBuild geen virtueel geheugen gebruikt :)

toegevoegd 02 november 2011 op 11:39, de auteur Ludwo, de bron

Maar het is niet waar. Ik heb het gecontroleerd en het faalde op dit probleem als het 800 MB gratis fysiek geheugen beschikbaar heeft.

toegevoegd 03 november 2011 op 08:01, de auteur Ludwo, de bron

Ik heb dezelfde problemen. Ik heb ook uit het geheugen verwijderde uitzonderingen gezien met betrekking tot deze fout. Beperking tot een simultane build helpt niet; er zijn nog steeds fouten: Bekijk de schermafbeelding hier ; de fout treedt precies op wanneer het geheugenverbruik het fysiek beschikbare geheugen overschrijdt. Het had een paar nauwe borstels met de dood en toen raakte het het maximum en stierf, daarbij Outlook en Process Explorer mee nemend, een JIT-debugger die niet zal starten, en het vrijgeven van MSBuild.exe om een zombie-proces te worden dat op het geheugen zit totdat ik het handmatig dood.

toegevoegd 01 november 2011 op 09:54, de auteur Kevin Vermeer, de bron

Ik gebruik 32bit MSBuild op een 32-bits WinXP-desktop met 2 GB fysiek en vergelijkbaar onbeperkt virtueel RAM-geheugen. Het rare is dat de crash optreedt wanneer het fysieke RAM volledig is opgebruikt. Het is alsof ik nul virtueel geheugen heb!

toegevoegd 02 november 2011 op 11:30, de auteur Kevin Vermeer, de bron

4 antwoord

de auteur Kevin Vermeer · Answer 1 · 2011-11-02T02:56Z

Zoals besproken in de uitwisseling van opmerkingen over de vraag:

Vreemd is dat ik 64bit MSBuild gebruik op een 64bit Win7-laptop met 4GB fysiek en "onbeperkt" virtueel RAM. MSBuild-proces gebruikt ongeveer 1 GB RAM (piek van 1,5 GB). - Ludwo 4 uur geleden

Ik gebruik 32bit MSBuild op een 32-bits WinXP-desktop met 2 GB fysiek en vergelijkbaar onbeperkt virtueel RAM-geheugen. Het rare is dat de crash optreedt wanneer het fysieke RAM volledig is opgebruikt. Het is alsof ik nul virtueel geheugen heb! - Kevin Vermeer 3 uur geleden

Ja, het lijkt erop dat MSBuild geen virtueel geheugen gebruikt :) - Ludwo 2 uur geleden

Het leek erop dat MSbuild geen virtueel geheugen gebruikte. Ik heb een aantal tests gedaan (een aantal programma's starten) en het leek erop dat nothing virtueel geheugen gebruikte. Ik deed wat zoekopdrachten die me moesten controleren

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

en ontdekte dat er een instelling bestaat die mijn systeemgrootte voor virtueel geheugen beperkt. Ik had me voorgenomen dat virtueel geheugen effectief oneindig was, of, meer precies, 4 GB voor elk proces op 32-bit XP. Ik naderde deze limiet niet. Mijn virtuele geheugenruimte was echter beperkt tot ... 0 MB. Niet cool, wie of wat dan ook.

Ik heb dit gewijzigd om een minimum van 1024 MB en een maximum van 4096 MB aan virtueel geheugen toe te wijzen. Ik heb de kolom 'Virtuele grootte' toegevoegd in Process Explorer , die samen met de "System Commit" -grafiek toont aan dat ik nu meer geheugen gebruik dan de hoeveelheid beschikbaar in de fysieke RAM-sticks.

Dit loste mijn problemen op. Jammer genoeg, mijn systeem maalt naar een bijna-halt telkens wanneer het probeert om een geheugen te pagina, maar dat is beter dan een crash. Ik heb parallelle builds opnieuw ingeschakeld; het parallelt en gebruikt veel CPU's terwijl ik RAM over heb (wat geldt voor de meeste bestanden) en dips tot 1% van het CPU-gebruik als ik geen RAM meer heb. Wanneer deze bestanden zijn voltooid, wordt de snelheid hersteld.

de auteur William Jockusch · Answer 2 · 2017-07-30T02:18Z

In mijn geval was het antwoord om Antlr bij te werken. Dit is uiteraard alleen van toepassing als u Antlr in uw project gebruikt.

de auteur David Q Hogan · Answer 3 · 2011-10-31T07:22Z

Er is mogelijk onvoldoende geheugen beschikbaar, waardoor een van de build-subprocessen mislukt: mislukt het minder als u/m: 2 gebruikt om het te beperken tot twee gelijktijdige builds? (ervan uitgaande dat je meer dan 2 kernen hebt)

Of, als u wat RAM van een andere machine kunt lenen of uw swap-grootte kunt vergroten, gebeurt dit minder vaak als er meer geheugen op uw build-machine is geïnstalleerd?

de auteur MikeBMcL · Answer 4 · 2011-11-05T04:47Z

Misschien is het het build-equivalent van een race-conditie?

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

Als u een gewone referentietag gebruikt voor een afhankelijkheid van de uitvoer van een ander project dat deel uitmaakt van de build (in plaats van een ProjectReference-tag), krijgt u mogelijk een situatie waarin gewoonlijk project X wordt voltooid vóór project Y (afhankelijk van project X's output) maar af en toe bouwen ze gelijktijdig, in welk geval de uitvoer van X niet zou bestaan wanneer Y er naar ging zoeken, waardoor Y faalde. Ik kan niets vinden over wat voor soort foutuitvoer MSBuild in die situatie geeft (en ik heb geen gemakkelijk beschikbare manier om het zojuist te testen), dus misschien is het dat niet.

Toch brengt de inconsistentie in de uitkomsten (vaak succesvol, soms faalt) me ertoe te vermoeden dat zoiets misschien de oorzaak kan zijn.