Question

每个人（至少每个使用编译语言的人）都面临编译错误，但实际上会使编译器崩溃多少次？

我已经公平地分享了“内部编译器错误”，但大多数人只是通过重新编译而离开了。你有一个（最小的）代码会崩溃编译器吗？

Answer 1

我编写了我们使用的编译器，因此有时会崩溃。

Answer 2

容易。

// -*- 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>`.

Answer 3

我还没有让GHC（一个Haskell编译器）崩溃，但是我已经把它弄错了

My brain just exploded.
I can't handle pattern bindings for existentially-quantified constructors.

这很容易解决，除非你有一些棘手的（通常是错误的）设计，否则你不会这样做，但它可能会成为有史以来最好的编译器错误消息。

Answer 4

VC现在优雅地捕获它，但在90年代中期，这将崩溃Microsoft C ++和Borland C ++编译器：

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


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

重载运算符 - ＆gt;本质上是递归的。期望该函数返回指针，该指针操作＆gt;再次适用于。这个片段使代码生成无限递归。

Answer 5

嗯，这实际上并没有使编译器崩溃 - 这只是一个bug，因为VC ++不会接受完美的代码。（details provided here）。

奇怪的是，这只是在三个相当模糊的条件都满足时触发的。移动一行代码就是有效解决方法所需的全部内容。其中一个必要的前提条件是“使用namespace std;”这在生产代码中被广泛劝阻。

然而，有关如何解决问题的消息是Microsoft VC ++新闻组的主要内容。我无法弄清楚有多少人偶然发现了一个不起眼的小虫。所以，最终，我问了一个人......

触发错误所需的确切代码是Stroustrup的“ The C ++ Programming Langauge ”中的一个例子。（*）

（*）注意，我不是说他是故意这样做的。我确定他在UNIX的C ++变种下进行了测试，完全没有意识到它对VC ++的影响。

Answer 6

Visual C ++ 9.0 SP1

这只是发生在我身上

------ 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 ==========

Answer 7

Actionscript 3.0：

switch(on_some_variable)
{
}

空开关= Kaboom！

Answer 8

我在C＃编译器中看到了一些编译器错误（所有边缘情况，都报告得恰当）并确认了其他人引发的一些崩溃。

我遇到的最可怕的编译器（一种）是一个Java版本中的JIT错误。它非常可重复，但导致VM崩溃。添加一个相当无操作的语句（我不记得究竟是什么随便 - 可能只是声明一个带有初始值的额外局部变量）使它远离它碰巧的任何角落情况 - 并且它在更高版本中得到修复。

Answer 9

这破坏了C64 BASIC：

PRINT 0 + "" +- 0

Answer 10

哎呀，忘记了typedef中的'e'并使编译器崩溃了。

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

Answer 11

这是一种使VS2003 C ++编译器崩溃的方法。

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

这将导致崩溃并出现以下错误消息

致命错误C1001：内部编译器错误（编译器文件'msc1.cpp'，行 2708）请选择技术 Visual C ++帮助中的支持命令菜单，或打开技术支持帮助文件以获取更多信息

在Tmap（定义{{1}}的第二行）后立即删除分号以消除错误。

Answer 12

今天VS2003SP1给了我一个C1001（内部编译器错误）抱怨编译器文件'msc1.cpp'，第2708行因为：

struct PATTERN {
  …
};

事实证明问题是我试图定义的结构名称（PATTERN）已经是刷子类型的GDI中的typedef。然而，不是告诉我符号已经定义（就像它对大多数其他事情一样），它不仅没有指出结构作为问题 - 我通过有选择地注释掉块来缩小问题，直到错误消失为止 - 但它也给了我上面提到的神秘错误，这个错误与指定的文件无关 - 我甚至无法检查这个问题。：|

我能够使用以下代码重现它：

    typedef int SOMETHINGOROTHER;
    struct SOMETHINGOROTHER {};

<强> > fatal error C1001: INTERNAL COMPILER ERROR
的 > (compiler file 'msc1.cpp', line 2708) …

以下代码给出了预期的错误消息：

struct SOMETHINGOROTHER {}; typedef int SOMETHINGOROTHER;

<强> > 'SOMETHINGOROTHER' : redefinition; different basic types

显然问题出在编译器的结构处理例程中。

我想知道VS2005 +是否做得更好......

Answer 13

Visual C ++ 5.'Nuff说。

Answer 14

是的，尤其是当它是一个旧的或维护不足的编译器时（GCC 2.95，C ++模式下的Tendra）。不过，我不会保留这些代码。

Answer 15

在Mono C＃编译器的1.2.x版本中，复杂的代码会崩溃（如果我没记错的话，嵌套的匿名代理）。幸运的是，在2.x发布时，我没有看到任何崩溃。

Answer 16

感谢@Nick，这会导致VS2005崩溃。

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

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

Answer 17

在我工作的项目中，Boost Lambda表达式的某些特定用法可能会导致Visual C ++编译器崩溃。（我们使用的是Visual Studio 2003）
编译器只会在发布版本期间崩溃，调试版本可以正常工作。

在团队中发生了一场关于lambda库的适当使用的宗教战争，我很感激编译器为我们解决了这个问题。： - ）

Answer 18

我使用pcc和gcc来编译我的旧OS项目。

我发现了一个错误，pcc和gcc都处理了一段非常重要的代码，它崩溃了pcc。（字符在我的平台上签名）

struct{
  char myvalue:1;
}mystruct;

pcc崩溃了，因为所有的bitfield值都必须是int，所以它确实有更多的bug，但是gcc错误地处理它。如果你考虑一下，看，它已签名，但只有一点空间。因此，它只能存储0和-1。好吧，gcc通过存储0或1来处理错误。

Answer 19

我之前通过运行内存来破坏了编译器。

给DOS编译器大约0.5mb的源代码。紧缩。

Answer 20

在我以前的工作中，我们有一个模拟器，因为能够崩溃（ICE）编译器或导致它们生成错误的代码而臭名昭着。当代码实际生成正确时，编译器需要15分钟才能生成单个源文件。 Visual Studio从未（只要我在那里工作）能够编译模拟器核心。

核心是从DSL自动生成的，生成的代码经常将编译器推向极限。

升级到GCC的新版本经常引起广泛的紧张：新版本会起作用吗？

Answer 21

当你收到消息“灾难性失败”时，你知道你正在尝试......

迈克尔

Answer 22

我成功地使F＃编译器崩溃了很多次;但这不公平，因为它是beta / alpha / research / etc编译器。

Answer 23

我曾写过一个能让电脑自发重启的C程序。一个缺点是它与我当时试图实现的mergesort没有任何关系。

幸运的是，一旦我发现指针错误，它就会消失。

Answer 24

我做到了。一些Delphi版本（比方说＃4）经常使用含有错误的错误信息而崩溃。

新版本（2006年及更高版本）稳定但不稳固。（7在这种情况下很棒）。

编译器崩溃通常发生在大型编辑和复杂项目的调试会话（许多dll）中。大多数情况下，重新启动ide就足够了。但有时您需要重新启动PC。

O和我曾经将OS2与编译器一起崩溃，因为交换文件变得太大了。

Answer 25

我有一些更有趣的事情：链接器内部错误......

你知道如何引起这种情况吗？

Answer 26

GCC 2.95中的模板支持（尽管我可能错误地记录了该版本）是错误的。各种结构会导致它崩溃。我找不到测试用例，但我认为模板的内部类（或模板的内部类）是获取编译器错误的一种方法。

Answer 27

不是编译器，但在Windows 7 64位下，Visual Studio 2008中的链接器每天都会崩溃几次。立即再次建造总是在没有崩溃的情况下工作。微软似乎并不关心...

对你的问题不是一个真正的答案，因为它不是代码本身导致它，但我总是愿意咆哮这个特定的问题： - ）

Answer 28

很久以前，我在控制数据计算机上使用COBOL。（如果这听起来很有趣，那就是。控制数据因其高性能的科学计算系统而闻名，而COBOL编译器则是一种事后的想法。）我不记得细节了，但我有一个我正在尝试的程序移植到更新的版本。我尝试了几种不同的方法，发现在崩溃编译器或将其置于无限循环之间我可以做出选择。

Answer 29

有一次我使用Python文档中的生成器示例时，它破坏了我们使用的Python版本。同一周，我的一位同事成功地误用了FFI，任何涉及数字3的计算都会导致python崩溃。

Answer 30

在为源引擎编译地图时，我已经崩溃了VVIS。

这算得上吗？

Answer 31

我的团队经常在我们的构建机器上使用csharp编译器发生随机内部编译器错误。我们通过清除每个目标的构建之间的所有bin / obj文件夹解决了这个问题。

Answer 32

我从未尝试使编译器崩溃，但是VB编译器/调试器每天都要多次出现在我身上。即使它是VB，这还算数吗？

Answer 33

我不知道是否会将其称为崩溃，但是sdcc（Small Device C Compiler）在编译以特定方式形成的代码时失败：

目标：8051
代码必须在从外部测试器加载的512字节高速缓存中执行
测试人员处于控制状态并存储代码 - 缓存无法获取下一页
不允许函数调用 - PC（程序计数器）将跳转到不驻留在缓存中的位置;预处理器宏用于完成模块化编码实践
如果跳过（分支），则不允许跳过缓存
没有const值 - 在程序代码的数据部分中导致缓存中的代码获取不在缓存中的内容 - 预处理器常量（#define）在这里

预处理器宏展开，导致平坦但代码很大 - main（）中的所有内容;执行跳过启动代码（设置堆栈等）并从main（）

的开头开始

此答案的相关部分：

有时，sdcc会拒绝编译语法正确的代码，并显示有关内存不足的消息。这甚至发生在具有8GB RAM的64位盒上进行编译。

这些情况下的解决方案是将固件拆分为单独的部分并单独编译并单独执行。这些碎片可能已经能够重新连接在一起，但此时并不重要。

我没有尝试过，但Keil 8051编译器可能已经处理了有问题的代码。

Answer 34

它没有像过去那样发生，但偶尔ASP.net预编译器有问题 - 我没有亲自看到它，但我已经修复了另一个项目的问题，因为他们有名字冲突，因为他们在预编译期间没有正确使用命名空间（导致编译器崩溃）。

在过去的好时光（非托管MSVC ++）中，我们遇到了奇怪的编译器崩溃，通常是由于外部静态win32类（.lib）中的链接和偶然引起问题的几个奇数位代码，但这些都是非常有用的快。

Answer 35

我设法将Python解释器分段。当然，我当时正在研究一个C扩展并且不太正确。

Answer 36

Microsoft Xbox 360编译器可能很容易崩溃。我获得了日语注释的源代码，当转换为常规文本时，该行的最后一个字符之一是'\'，因此它将注释继续到下一行。如果下一行是switch命令，则编译器崩溃。

//wierd japanese characters here %^$$\
switch(n)
{
case 0:
    .....
break;
case 1:
    .....
break;
}

Answer 37

当编译C ++时VC ++已经崩溃，如果模板使用被搞砸了（例如，在结束时错过了“＆gt;”）。

Answer 38

我已经多次崩溃VC ++，通常是模板代码。但这不是最有趣的崩溃......

我使用/ analyze选项编译了VS2005 Team System编译器，编译了我的共享代码库，在没有交换机的情况下编译时没有错误，在带有和不带交换机的VS2008上编译。当然MS不是很感兴趣，因为它是旧版本编译器中的一个错误，但我认为它非常有趣。

Answer 39

我多次破坏Delphi 7，要求它编译遗留的dos代码。

罪魁祸首似乎是对系统单元中任何东西的任何限定。这并不会总是炸毁它，但是当它在这些东西上爆炸时，我会查看并重写任何需要这种覆盖的东西，问题就会消失。

爆炸是100％可重现的，但我从未设法做出简单的测试用例。它实际上并没有在大多数情况下使编译器崩溃，你通常会得到一个与问题无关的错误，并且可能有数百行。环境不稳定，保存和退出是可以的，但不要考虑做任何其他事情。

回到与Borland Pascal 7（最后的dos版本）的石器时代，我打破了很多次。没有崩溃，只是错误和不一致的代码发射。我终于学会了将.EXE（不计入调试信息）保持在3mb以下。它越远，我就越不稳定。

你有没有崩溃编译器？

39 个答案: