Ich habe keine Antwort auf dieses genaue Problem, aber ich kann versuchen, Ihnen einen Hinweis darauf zu geben, was passieren könnte:Fehlende Abhängigkeiten in Makefiles.
Beispiel:
target: a.bytecode b.bytecode
link a.bytecode b.bytecode -o target
a.bytecode: a.source
compile a.source -o a.bytecode
b.bytecode: b.source
compile b.source a.bytecode -o a.bytecode
Wenn Sie make target anrufen alles wird korrekt kompiliert. Zusammenstellung von a.source zuerst (willkürlich, aber deterministisch) durchgeführt. Dann Kompilierung von b.source durchgeführt wird.
Aber wenn Sie make -j2 target beide compile Befehle werden parallel ausgeführt. Und Sie werden tatsächlich feststellen, dass die Abhängigkeiten Ihres Makefiles unterbrochen sind. Die zweite Kompilierung geht von a.bytecode aus ist bereits kompiliert, taucht aber nicht in Abhängigkeiten auf. Es ist also wahrscheinlich, dass ein Fehler passiert. Die richtige Abhängigkeitszeile für b.bytecode sollte sein:
b.bytecode: b.source a.bytecode
Um auf Ihr Problem zurückzukommen, wenn Sie kein Glück haben, kann es sein, dass ein Befehl aufgrund einer fehlenden Abhängigkeit in einer 100% CPU-Schleife hängt. Das ist wahrscheinlich, was hier passiert, die fehlende Abhängigkeit konnte nicht durch einen sequentiellen Build aufgedeckt werden, aber es wurde durch Ihren parallelen Build aufgedeckt.
Ich weiß nicht, wie lange Sie die Maschine schon haben, aber meine erste Empfehlung wäre, einen Speichertest zu machen und zu überprüfen, ob der Speicher richtig funktioniert. Ich weiß, dass oft nicht der Arbeitsspeicher das Problem ist, aber wenn doch, ist es am besten, ihn zuerst als Ursache zu eliminieren, bevor Sie versuchen, andere wahrscheinliche Probleme aufzuspüren.
Mir ist klar, dass dies eine wirklich alte Frage ist, aber sie taucht immer noch ganz oben in den Suchergebnissen auf, also hier ist meine Lösung:
GNU make hat einen Jobserver-Mechanismus, um sicherzustellen, dass make und seine rekursiven Kinder nicht mehr als die angegebene Anzahl von Kernen verbrauchen:http://make.mad-scientist.net/papers/jobserver-implementation/
Es stützt sich auf eine Pipe, die von allen Prozessen gemeinsam genutzt wird. Jeder Prozess, der weitere Kinder forken möchte, muss zuerst Token aus der Pipe verbrauchen und sie dann freigeben, wenn er fertig ist. Wenn ein untergeordneter Prozess die von ihm verbrauchten Token nicht zurückgibt, bleibt das Make der obersten Ebene hängen, während es ewig darauf wartet, dass sie zurückgegeben werden.
https://bugzilla.redhat.com/show_bug.cgi?id=654822
Ich bin auf diesen Fehler gestoßen, als ich binutils mit GNU make auf meiner Solaris-Box erstellt habe, wobei „sed“ nicht GNU sed ist. Das Herumspielen mit PATH, um sed==gsed Vorrang vor dem System sed zu geben, hat das Problem behoben. Ich weiß allerdings nicht, warum sed Token aus der Pipe konsumiert hat.