BEARBEITEN 2
Ich habe das Problem "gelöst", aber ich möchte es nicht als Antwort veröffentlichen, es erklärt nicht, was tatsächlich passiert ist. Im Code für .NET resourceReader.exe verwende ich
um die internationalisierten Ressourcen in Unicode in stdout auszugeben. Wenn ich die Codierung am Ende meines Programms mit
Dann bekomme ich keine Fehler in Node. Wenn ich es nicht zurücksetze, erhalte ich den in der ursprünglichen Frage beschriebenen Fehler. Es scheint, dass .NET einige der Einstellungen für die Ausgabecodierung in cmd.exe durcheinander bringt und dazu führt, dass der nachfolgende Knotenlauf fehlschlägt!
BEARBEITEN
Ich habe den Fehler so eingeschränkt, dass er von resourceReader.exe verursacht wurde. Es ist ein .NET-Programm, das einige Ressourcenströme aus der .NET-Assembly liest und sie mit Console.WriteLine in die Standardausgabe ausgibt. Ich habe Console.OutputEncoding = System.Text.Encoding.UTF8 zu resourceReader.exe hinzugefügt, weil einige der Ressourcen in Nicht-ASCII-Buchstaben stehen und das ist der Grund für den Absturz in grunt!
Wenn ich diese Zeile herausbringe, stürzt die Aufgabe nicht ab, aber die Ressourcen erscheinen in nicht druckbaren ASCII-Zeichen! Außerdem geschieht der Absturz nur, wenn ich tatsächlich Nicht-ASCII in sdtout drucke. Wenn ich sie nicht drucke, ist es kein Fehler.
ORIGINAL
Ich habe meiner Gruntdatei einen Schritt hinzugefügt, der child_process.execFile benutzt, um einige Daten von einem externen Programm zu lesen und im Build zu verwenden. Jetzt, wenn ich meine Build starte, läuft es beim ersten Mal gut, stürzt aber beim zweiten Mal ab!
Hier ist die Ausgabe des Absturzes (das ist während der Uglify-Aufgabe):
%Vor%Hier ist der Code für die Aufgabe, die child_process verwendet.
%Vor%Hier sind einige Dinge, die ich beim Debuggen entdeckt habe, die hilfreich sein könnten
> filename oder | process ), läuft es gut cmd.exe ), funktioniert es einwandfrei exit und close des untergeordneten Prozesses einen Listener hinzugefügt, der rdr.on("close", function() { console.log("close"); }); und das gleiche für den Ausgang verwendet. Beide Ereignisse werden wie erwartet im ersten Lauf ausgelöst. node.exe unter der Eingabeaufforderung öffnen und wieder schließen, wenn mein Befehl beendet ist. Unter der Eingabeaufforderung sind keine Prozesse sichtbar "offen gelassen". Interessant ist, dass der Stack-Trace letztendlich einen socket.write -Fehler anzeigt. Nichts in dem von Ihnen bereitgestellten Code deutet darauf hin, dass Sie versuchen, in einen Socket zu schreiben.
Wenn wir dem Stack nach unten folgen, können wir sehen, dass Grunt tatsächlich versucht, in einen Socket zu schreiben, während er versucht, eine nicht abgefangene Ausnahme zu protokollieren.
Also zuerst wirft Ihre Grunt-Aufgabe einen momentan unbekannten Fehler und dann grunzen Sie sich selbst Fehler, weil es Ihnen davon nicht erzählen kann.
Ich würde zuerst versuchen, den Fehler in Ihrem Kindprozess zu protokollieren. Derzeit, wenn ein Fehler vorliegt, einfach throw es ohne herauszufinden, was es ist. Es ist wahrscheinlich, dass dies das ist, was Grunt versucht und nicht protokolliert.
Ersetzen
if (err) throw new Error(err);
Mit
if (err) console.error(err);
Dies wird hoffentlich das Problem socket.write vermeiden und Ihnen spezifische Informationen darüber geben, welcher Fehler im untergeordneten Prozess auftritt. Was siehst du?
Zweitens würde ich versuchen, child_process.exec anstelle von child_process.execFile zu verwenden. Dies erzeugt eine Shell und führt resourceReader.exe darin aus (anstatt sie direkt auszuführen). Dies kann helfen, Probleme zu vermeiden, die bei laufendem / fehlgeschlagenem Befehl im Hintergrund auftreten, was die Ursache für den Fehler socket.write sein kann.
Tags und Links .net c# gruntjs node.js child-process