[Language-agnostic] Haben Sie jemals den Compiler abgestürzt?


Answers

einfach.

// -*- C++ -*-

template <int n>
class Foo : public Foo<n+1>
{

};

int main(int, char*[])
{
    Foo<0> x;
    return 0;
};


ejgottl@luna:~/tmp$ g++ -ftemplate-depth-1000000 -Wall foo.cpp -o foo
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See `<URL:http://gcc.gnu.org/bugs.html>` for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
`<URL:file:///usr/share/doc/gcc-4.2/README.Bugs>`.
Question

Jeder (zumindest jeder, der eine kompilierte Sprache verwendet) hat mit Kompilierungsfehlern zu kämpfen gehabt, aber wie oft kommt es dazu, dass der Compiler tatsächlich abstürzt?

Ich hatte meinen gerechten Anteil an "internen Compilerfehlern", aber die meisten gingen einfach durch erneutes Kompilieren davon. Haben Sie einen (minimalen) Code, der den Compiler abstürzt?




Hier ist eine Möglichkeit, den VS2003 C ++ - Compiler zum Absturz zu bringen.

typedef map<int,int> Tmap;
private: Tmap; * m_map;

Dies führt zu einem Absturz und der folgenden Fehlermeldung

Schwerwiegender Fehler C1001: INTERNER COMPILER-FEHLER (Compiler-Datei 'msc1.cpp', Zeile 2708) Wählen Sie im Menü der Visual C ++ - Hilfe den Befehl Technischer Support oder öffnen Sie die Hilfedatei des technischen Supports für weitere Informationen.

Entfernen Sie das Semikolon unmittelbar nach Tmap (zweite Zeile, die m_map definiert), um den Fehler zu beseitigen.




Als ich einmal das Generator-Beispiel aus den Python-Dokumenten verwendete, brach es die Version von Python, die wir verwendeten. In der gleichen Woche gelang es einem meiner Kollegen, das FFI so zu missbrauchen, dass jede Berechnung mit der Nummer 3 Python abstürzen lassen würde.




Ich habe ein paar Compiler-Fehler im C # -Compiler gesehen (alle Edge-Fälle, die alle richtig berichtet haben) und einige Abstürze bestätigt, die von anderen Leuten provoziert wurden.

Der gruseligste Compiler-Fehler, der mir begegnete, war ein JIT-Bug in einer Java-Version. Es war sehr gut reproduzierbar, verursachte aber einen Abfall der VM. Hinzufügen einer ziemlich no-op-Anweisung (Ich kann mich nicht erinnern, was nebenbei - möglicherweise nur eine lokale Variable mit einem Anfangswert deklariert) es weg von jedem Ecke Fall verschoben, es war zufällig - und es wurde in einer späteren Version behoben.




VC fängt es jetzt anmutig, aber Mitte der 90er Jahre würde dies sowohl Microsoft C ++ - als auch Borland-C ++ - Compiler abstürzen lassen:

struct MyClass
{
    MyClass operator->() { return *this; }
};


int main(int argc, char* argv[])
{
    MyClass A;
    A->x;
}

Ein überladener Operator-> ist intrinsisch rekursiv. Es wird erwartet, dass die Funktion einen Zeiger zurückgibt, auf den oper-> erneut angewendet wird. Dieses Fragment hat die Codegenerierung unendlich rekursiv gemacht.




Ich stürzte Delphi 7 viele Male und fragte ihn, Legacy DOS-Code zu kompilieren.

Der Hauptschuldige scheint jede Qualifikation von etwas zu sein, das sich in der Systemeinheit befindet. Das wird es nicht immer in die Luft jagen, aber wenn es in solchen Dingen explodiert, schaue ich durch und schreibe alles um, was eine solche Überwindung erfordert, und das Problem verschwindet.

Die Blowups sind 100% reproduzierbar, aber ich habe es nie geschafft, einen einfachen Testfall zu machen. Es stürzt den Compiler die meiste Zeit nicht ab, normalerweise erhalten Sie einen Fehler, der nichts mit dem Problem zu tun hat, und können Hunderte von Zeilen davon sein. Die Umgebung ist destabilisiert, Speichern und Beenden ist in Ordnung, aber denken Sie nicht daran, etwas anderes zu tun.

Zurück in der Steinzeit mit Borland Pascal 7 (die letzte dos Version) habe ich es viele Male gebrochen. Kein Absturz, nur falsche und inkonsistente Codeemission. Ich habe schließlich gelernt, die .EXE (ohne Debug-Info) unter 3 MB zu halten. Je weiter ich kam, desto instabiler wurde es.




Hoppla, vergaß ein 'e' in typedef und stürzte den Compiler ab.

typdef struct kGUIColor GameColor;

c:\source\kgui\samples\space\space.cpp(35) : fatal error C1001: INTERNAL COMPILER ERROR
        (compiler file 'msc1.cpp', line 2708) 
         Please choose the Technical Support command on the Visual C++ 
         Help menu, or open the Technical Support help file for more information



VC ++ ist bei der Kompilierung von C ++ auf mich abgestürzt, wenn die Verwendung von Templates vermasselt ist (z. B. wenn ein schließendes ">" fehlt).




In der Version 1.2.x des Mono C # -Compilers würde einiges mit kompliziertem Code abstürzen (wenn ich mich richtig erinnere, verschachtelte anonyme Delegates). Glücklicherweise habe ich mit der Version 2.x keine Abstürze gesehen.




Dank @Nick stürzt dies VS2005 ab.

 template<typename Res, typename T>
 Res operator_cast(const T& t)
 {
     return t.operator Res();
 }

 int main()
 {
    return operator_cast<int>(0);
 }



Wenn Sie die Meldung "Katastrophales Versagen" erhalten, wissen Sie, dass Sie es versuchen ....

Michael




Ja, vor allem, wenn es sich um einen alten oder nicht mehr gepflegten Compiler handelt (GCC 2.95, Tendra im C ++ - Modus). Ich bewahre jedoch nicht die Codestücke auf.




Ich weiß nicht, ob ich es als Absturz bezeichnen würde, aber sdcc ( Small Device C Compiler ) schlägt beim Kompilieren von Code fehl, der auf eine bestimmte Weise erstellt wurde:

  • Ziel: 8051
  • Code musste in einem 512 Byte Cache ausgeführt werden, der von einem externen Tester geladen wurde
  • Tester kontrolliert und speichert den Code - Cache kann die nächste Seite nicht abrufen
  • Keine Funktionsaufrufe erlaubt - der PC (Programmzähler) springt zu einem Ort, der nicht im Cache resident ist; Präprozessormakros wurden verwendet, um eine modulare Codierungspraxis zu erreichen
  • Sprünge (Verzweigung) erlaubt, wenn sie nicht aus dem Cache springen
  • Keine konstanten Werte - im Datenabschnitt des Programmcodes, der bewirkt, dass Code im Cache etwas nicht im Cache abruft - Präprozessorkonstante (#define) OK hier

Die Präprozessor-Makros werden entrollt, was zu einem flachen, aber großen Code führt - alles in main (); Die Ausführung überspringt den Startcode (Einrichten des Stacks usw.) und beginnt am Anfang von main ()

Ein relevanter Teil dieser Antwort:

Gelegentlich weigerte sich sdcc, syntaktisch korrekten Code zu kompilieren, mit einer Meldung über den Mangel an Arbeitsspeicher. Dies geschah sogar auf 64-Bit-Boxen mit 8 GB RAM.

In diesen Fällen bestand die Lösung darin, die Firmware in einzelne Teile aufzuteilen und separat zu kompilieren und separat auszuführen. Die Stücke konnten vielleicht wieder miteinander verbunden werden, aber an diesem Punkt spielte es keine Rolle.

Ich habe es nicht probiert, aber der Keil 8051 Compiler hätte wahrscheinlich den problematischen Code behandeln können.




Ich konnte den Python-Interpreter segfault. Natürlich habe ich damals an einer C-Erweiterung gearbeitet und sie nicht ganz richtig gemacht.




Visual C ++ 9.0 SP1

das ist mir gerade passiert

------ Build started: Project: pdfp, Configuration: Debug Win32 ------
Compiling...
reader.cpp
xref.cpp
c:\projects\pdfp\xref.cpp(52) : fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\toil.c', line 8569)
 To work around this problem, try simplifying or changing the program near the locations listed above.
Please choose the Technical Support command on the Visual C++ 
 Help menu, or open the Technical Support help file for more information
Generating Code...
Build log was saved at "file://c:\Projects\pdfp\Debug\BuildLog.htm"
pdfp - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========