eroare MSB4166: nodul copil a părăsit prematur. Opriți-vă

Uneori construirea mea nu reușește cu această eroare.

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

Pare a fi complet aleator și nu am reușit să o reproduc la nevoie. Am rulat VS2010 Win7 x64 MSBuild 4.0, dar această problemă pare a fi platformă și OS independente. Am construit soluții în paralel (/ m switch + BuildInParallel = True) și nu vreau să dezactivez această caracteristică deoarece compilez aplicație care conține 800+ proiecte. Ai idee cum să o rezolvi?

EDIT: Când am instalat previzualizarea dezvoltatorului .NET 4.5, logarea erorilor a fost îmbunătățită în MSBuild 4.5 și acum șirul de eroare arată astfel:

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

Pot găsi fișier jurnal de eroare în dosarul Temp. Acesta este conținutul fișierului 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
Un lucru ciudat este că folosesc 64bit MSBuild pe 64bit Win7 laptop cu 4GB de fizică și "nelimitat" RAM virtuale. Procesul MSBuild utilizează aproximativ 1GB de RAM (vârf 1,5 GB).
adăugat autor Ludwo, sursa
Da, se pare că MSBuild nu folosește memoria virtuală :)
adăugat autor Ludwo, sursa
Dar nu este adevărat. Am verificat-o și a eșuat în această problemă dacă are 800 MB de memorie fizică liberă disponibilă.
adăugat autor Ludwo, sursa
Am aceleași probleme. De asemenea, am văzut excepții în afara memoriei legate de această eroare. Restrângerea la o construire simultană nu ajută; încă erori: Consultați captura de ecran aici ; eroarea apare tocmai atunci când consumul de memorie depășește memoria fizică disponibilă. Avea câteva perii apropiate cu moartea, apoi a lovit maximul și a murit, luând cu ea Outlook și Process Explorer, oferind un program de depanare JIT care nu va porni și eliberând MSBuild.exe pentru a deveni un proces zombie așezat pe memorie până când o omor.
adăugat autor Kevin Vermeer, sursa
Folosesc 32bit MSBuild pe un desktop WinXP pe 32 de biți cu 2 GB de memorie virtuală RAM fizică și nelimitată. Lucrul ciudat este că se produce un accident când RAM fizic este complet consumat. E ca și cum am o memorie virtuală zero!
adăugat autor Kevin Vermeer, sursa

4 răspunsuri

După cum sa discutat în schimbul de comentarii la întrebarea:

Un lucru ciudat este că folosesc 64bit MSBuild pe 64bit Win7 laptop cu 4GB de fizică și "nelimitat" RAM virtual. Procesul MSBuild utilizează aproximativ 1GB de RAM (vârf 1,5 GB). - Ludwo acum 4 ore

Folosesc 32bit MSBuild pe un desktop WinXP pe 32 de biți cu 2 GB de memorie virtuală RAM fizică și nelimitată. Lucrul ciudat este că se produce un accident când RAM fizic este complet consumat. E ca și cum am o memorie virtuală zero! - Kevin Vermeer acum 3 ore

Da, se pare că MSBuild nu folosește memoria virtuală :) - Ludwo 2 ore în urmă

Se pare că MSbuild nu folosea memoria virtuală. Am făcut niște teste (pornind o grămadă de programe) și părea că nimic nu folosea memoria virtuală. Am făcut câteva căutări care mă determină să verific

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

și am constatat că există o setare care a limitat dimensiunea mea de memorie virtuală la nivel de sistem. Îmi imaginam că memoria virtuală este efectiv infinită sau, mai precis, 4 GB pentru fiecare proces pe 32 de biți XP. Nu mă apropia de această limită. Cu toate acestea, spațiul meu virtual de memorie a fost limitat la ... 0MB. Nu se răcește, oricine ar fi făcut asta.

Am schimbat acest lucru pentru a aloca un minim de 1024 MB și un maxim de 4096 MB de memorie virtuală. Am adăugat coloana "Dimensiune virtuală" în Process Explorer , care, împreună cu "System Commit", demonstrează că acum folosesc mai multă memorie decât cantitatea disponibilă în memoria RAM fizică.

Acest lucru mi-a rezolvat problemele. Din păcate, sistemul meu se îngrădește aproape de fiecare dată când încearcă să citească orice memorie, dar asta e mai bine decât un accident. Am re-activat construirile paralele; paralelizează și folosește o mulțime de CPU în timp ce am rămas RAM (ceea ce este adevărat pentru majoritatea fișierelor) și scade la 1% din utilizarea CPU când nu mai am RAM. Când aceste fișiere sunt terminate, viteza este restabilită.

2
adăugat
VM-ul meu este activat și gestionat de sistem
adăugat autor Ludwo, sursa
Nu este problema de setări VM. Am 800 MB de memorie liberă. Acum voi verifica dacă este cauzată de extensii de 32bit sau nu ...
adăugat autor Ludwo, sursa
@Ludwo - Este un lucru bun și există cu siguranță multe cauze posibile pentru acest tip de eroare, dar ați încercat să-l setați manual?
adăugat autor Kevin Vermeer, sursa

În cazul meu, răspunsul a fost să actualizeze Antlr. Evident, acest lucru se aplică numai dacă utilizați Antlr în proiectul dvs.

1
adăugat

S-ar putea să vă epuizați memoria, cauzând eșecul unuia dintre subprocesele construirii - nu eșuează mai puțin dacă utilizați/m: 2 pentru al restrânge la două compilații simultane? (presupunând că aveți mai mult de 2 nuclee)

Sau, dacă puteți împrumuta unele RAM de la o altă mașină sau puteți mări dimensiunea swap-ului dvs., se întâmplă mai puțin când aveți mai multă memorie instalată pe mașina dvs. de construit?

1
adăugat
Am doar 2 nuclee. Construcția mea uneori eșuează din excepția de memorie. Voi face o investigație și vă voi anunța ...
adăugat autor Ludwo, sursa
Am o mulțime de memorie liberă și nu mi-a reușit din nou. Ar trebui să fie oarecum legată de limitarea procesului de 32bit, deoarece construirea mea utilizează mai mult de 2GB de memorie RAM. Dar nu văd cum ar trebui să fie posibil, deoarece procesul meu MSBuild este 64bit.
adăugat autor Ludwo, sursa

Poate că e echivalentul de construcție al unei condiții de cursă?

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

Dacă utilizați o etichetă de referință obișnuită pentru o dependență de ieșirea unui alt proiect care face parte din construirea (mai degrabă decât o etichetă ProjectReference), ați putea obține o situație în care, de obicei, proiectul X se termină înainte de proiectul Y (care depinde de proiectul X ieșire), dar ocazional se construiesc simultan, caz în care rezultatul lui X nu ar exista atunci când Y a mers să îl caute, determinând Y să eșueze. Nu pot găsi nimic despre ce tip de eroare le dă MSBuild în acea situație, totuși (și nu au o modalitate ușor de testat-o ​​chiar acum), așa că poate că nu este.

Încă inconsecvența rezultatelor (adesea reușită, ocazional eșuează) mă determină să suspectez că poate fi o cauză de genul acesta.

1
adăugat
Nu. Am un număr mare de proiecte în mai multe soluții. Eu folosesc sarcina mea de fuziune pentru fuziunea soluțiilor și eu creez o soluție mare înainte ca fiecare construcție să fie capabilă să construiască toate proiectele în paralel. În soluția de fuziune am transformat toate referințele în referințe ale proiectelor, dacă este posibil. Deci, fișierele mele de proiect sunt actualizate după ce fuzionează soluțiile așa cum este descris în exemplul 2 din articolul dvs. conectat.
adăugat autor Ludwo, sursa
+1 pentru răspunsul dvs. deoarece mi-ați explicat în mod indirect de ce numai o instanță a MSBuild este activă în timp ce alte instanțe sunt inactive. În discuție am găsit linkul la acest bug . Acesta este fixat în viitoarea versiune MSBuild după v4.0. Trebuie să-mi împărțesc proiectele în părți mai mici pentru a îmbunătăți performanța msbuild :(
adăugat autor Ludwo, sursa
Mulțumiri! Deci, acest lucru este normal când acest mare proiect a fost compilat primul și toate celelalte proiecte dependente îl așteptau.
adăugat autor Ludwo, sursa
@Ludwo - Dacă ajută, am avut 8 proiecte în soluția mea când am găsit și am rezolvat această problemă. Au fost împărțite în aproximativ 800 de fișiere și 16.000 de linii de cod; aproximativ 40% din acestea au fost incluse într-un singur proiect.
adăugat autor Kevin Vermeer, sursa