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 bewerkt
Bekeken: 13
de bron
ro ru fr es pt de zh hi bn ar kk be uk
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 de auteur Ludwo, de bron
Ja, het lijkt erop dat MSBuild geen virtueel geheugen gebruikt :)
toegevoegd 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 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 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 de auteur Kevin Vermeer, de bron

4 antwoord

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.

2
toegevoegd
de bron
Mijn VM is ingeschakeld en systeembeheer
toegevoegd de auteur Ludwo, de bron
Het is geen probleem met VM-instellingen. Ik heb 800 MB vrij geheugen. Nu zal ik controleren of het wordt veroorzaakt door 32-bits extensies of niet ...
toegevoegd de auteur Ludwo, de bron
@Ludwo - Dat is een goede zaak, en er zijn zeker veel mogelijke oorzaken voor dit soort fouten, maar heb je geprobeerd het handmatig in te stellen?
toegevoegd de auteur Kevin Vermeer, de bron

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

1
toegevoegd
de bron

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?

1
toegevoegd
de bron
Ik heb maar 2 kernen. Mijn build mislukt soms uit de geheugenuitzondering. Ik zal wat onderzoek doen en ik zal het je laten weten ...
toegevoegd de auteur Ludwo, de bron
Ik heb veel gratis geheugen en mijn mislukte opnieuw. Het zou op de een of andere manier gerelateerd moeten zijn aan 32bit procesgeheugenbeperking omdat mijn build meer dan 2GB RAM gebruikt. Maar ik zie niet hoe het mogelijk zou moeten zijn, omdat mijn MSBuild-proces 64bit is.
toegevoegd de auteur Ludwo, de bron

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.

1
toegevoegd
de bron
Nee. Ik heb enorm veel projecten in meerdere oplossingen. Ik gebruik mijn merge-taak voor het samenvoegen van oplossingen en ik maak vóór elke build één grote oplossing om alle projecten parallel te kunnen bouwen. In de taak Samenvoegoplossingen converteer ik alle verwijzingen zo mogelijk in projectreferenties. Dus mijn projectbestanden worden bijgewerkt nadat oplossingen zijn samengevoegd zoals beschreven in example2 in uw gekoppelde artikel.
toegevoegd de auteur Ludwo, de bron
+1 voor je antwoord omdat je indirect hebt uitgelegd waarom slechts één instantie van MSBuild actief is terwijl andere instanties niet actief zijn. In de discussie vond ik een link naar this bug . Het is opgelost in toekomstige MSBuild-release na v4.0. Ik moet mijn projecten in kleinere delen splitsen om de prestaties van msbuild te verbeteren :(
toegevoegd de auteur Ludwo, de bron
Bedankt! Dit is normaal toen dit grote project het eerst werd samengesteld en alle andere afhankelijke projecten erop wachtten.
toegevoegd de auteur Ludwo, de bron
@Ludwo - Als het helpt, had ik 8 projecten in mijn oplossing toen ik dit probleem ontdekte en verholpen. Ze zijn gesplitst in ongeveer 800 bestanden en 16.000 regels code; ongeveer 40% hiervan was onderdeel van een project.
toegevoegd de auteur Kevin Vermeer, de bron