每个人(至少每个使用编译语言的人)都遇到过编译错误,但是您实际上使编译器崩溃了多少次?
我有相当一部分“内部编译器错误”,但大多数只是通过重新编译而消失了。您是否有一段(最少的)代码会使编译器崩溃?
每个人(至少每个使用编译语言的人)都遇到过编译错误,但是您实际上使编译器崩溃了多少次?
我有相当一部分“内部编译器错误”,但大多数只是通过重新编译而消失了。您是否有一段(最少的)代码会使编译器崩溃?
我编写了我们使用的编译器,所以它有时会崩溃。
简单的。
// -*- 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>`.
我还没有让 GHC(一个 Haskell 编译器)崩溃,但是我已经让它出错了
My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors.
它很容易解决,除非你有一些棘手的(通常是错误的)设计,否则你不会遇到这个问题,但它可能会成为有史以来最好的编译器错误消息。
VC 现在可以优雅地捕捉到它,但在 90 年代中期,这会导致 Microsoft C++ 和 Borland C++ 编译器崩溃:
struct MyClass
{
MyClass operator->() { return *this; }
};
int main(int argc, char* argv[])
{
MyClass A;
A->x;
}
重载的 operator-> 本质上是递归的。该函数应返回一个指针,oper-> 再次应用于该指针。这个片段使代码生成无限递归。
动作脚本 3.0:
switch(on_some_variable)
{
}
空开关 = Kaboom!
视觉 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 ==========
好吧,这实际上并没有使编译器崩溃——这只是一个错误,VC++ 不能接受完美的代码。(此处提供详细信息)。
奇怪的是,它只有在三个相当模糊的条件都满足时才会触发。移动一行代码是有效解决方法所需要的。所需的先决条件之一是“使用命名空间标准;” 这在生产代码中被广泛劝阻。
尽管如此,询问如何解决问题的消息仍然是 Microsoft VC++ 新闻组的主要内容。我不知道有多少人偶然发现了一个不起眼的错误。所以,最后,我问了一个人......
触发该错误所需的确切代码是 Stroustrup 的“ C++ 编程语言”中的一个示例。(*)
(*) 注意,我不是说他是故意的。我确信他在 C++ 的 UNIX 变体下对其进行了测试,并且完全不知道它对 VC++ 的影响。
我在 C# 编译器中看到了一些编译器错误(所有边缘情况,均已正确报告),并确认了其他人引发的一些崩溃。
我遇到的最可怕的编译器(某种)错误是一个 Java 版本中的 JIT 错误。这是非常可重现的,但导致虚拟机停机。添加一个相当无操作的语句(我不记得究竟是什么副手 - 可能只是用初始值声明了一个额外的局部变量)将它从它碰巧的任何极端情况中移开 - 它在以后的版本中得到了修复。
这使 C64 BASIC 崩溃:
PRINT 0 + "" +- 0
是的,尤其是当它是一个旧的或维护不足的编译器时(GCC 2.95,C++ 模式下的 Tendra)。不过,我不会保留这些代码。
Visual C++ 5. 'Nuff 说。
糟糕,忘记了 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
Here's a way to crash the VS2003 C++ compiler.
typedef map<int,int> Tmap;
private: Tmap; * m_map;
This will result in a crash and the following error message
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
Remove the semicolon immediately after Tmap
(second line which defines m_map
) to eliminate the error.
在我工作的一个项目中,Boost Lambda表达式的一些特定用法可能会导致 Visual C++ 编译器崩溃。(我们使用的是 Visual Studio 2003)
编译器只会在发布版本期间崩溃,调试版本可以正常工作。
关于 lambda 库的适当使用在团队中发生了一场激烈的宗教战争,我几乎很感激编译器为我们解决了这个问题。:-)
在 Mono C# 编译器的 1.2.x 版本中,复杂的代码会导致相当多的崩溃(如果我没记错的话,嵌套的匿名委托)。幸运的是,在 2.x 版本中,我没有看到任何崩溃。
在我之前的工作中,我们有一个模拟器,它因能够使 (ICE) 编译器崩溃或导致它们生成错误代码而臭名昭著。当代码实际生成正确时,编译器通常需要 15 分钟才能生成单个源文件。Visual Studio 从来没有(只要我在那里工作)能够编译模拟器核心。
核心是从 DSL 自动生成的,生成的代码经常将编译器推到极限。
升级到新版本的 GCC 经常引起广泛的紧张:新版本会工作吗?
感谢@Nick,这会使 VS2005 崩溃。
template<typename Res, typename T>
Res operator_cast(const T& t)
{
return t.operator Res();
}
int main()
{
return operator_cast<int>(0);
}
我之前因为内存不足而使编译器崩溃。
给一个 DOS 编译器大约 0.5mb 的源代码。紧缩。
当您收到“灾难性失败”消息时,您知道您正在尝试....
迈克尔
I use both pcc and gcc to compile my old OS project.
I found a bug with how both pcc and gcc handle a non-trivial piece of code and it crashed pcc. (chars are signed on my platform)
struct{
char myvalue:1;
}mystruct;
pcc crashed because all bitfield values must be int though, so it's really more buggy there, but gcc handles it wrongly. See, if you think about it, it is signed, but only has room for one bit. So therefore, it only can store 0 and -1. Well, gcc handles it wrong by storing 0 or 1.
如果模板使用混乱(例如,错过了结束的“>”),VC++ 在编译 C++ 时让我崩溃了。
我做到了。一些 Delphi 版本(比如说 #4)经常崩溃,并带有神秘的错误消息。
较新的版本(2006 及更高版本)稳定但不坚如磐石。(在那种情况下,7 很棒)。
编译器崩溃经常发生在大型编辑和复杂项目(大量 dll)的调试会话中。大多数情况下,重新启动 ide 就足够了。但有时您需要重新启动 PC。
O 和我曾经因为交换文件变得太大而导致 OS2 和编译器一起崩溃。
有一次,当我使用 Python 文档中的生成器示例时,它破坏了我们正在使用的 Python 版本。同一周,我的一位同事设法滥用了 FFI,以至于任何涉及数字 3 的计算都会使 python 崩溃。
Microsoft Xbox 360 编译器很容易崩溃。我得到了带有日文注释的源代码,当转换为常规文本时,该行的最后一个字符是“\”,因此它将注释继续到下一行。如果下一行是一个 switch 命令,那么编译器就会崩溃。
//wierd japanese characters here %^$$\
switch(n)
{
case 0:
.....
break;
case 1:
.....
break;
}
我曾多次让 Delphi 7 崩溃,要求它编译遗留的 dos 代码。
罪魁祸首似乎是某种东西在系统单元中的任何资格。这并不总是会炸毁它,但是当它炸毁这些东西时,我会查看并重写任何需要这种覆盖的东西,问题就会消失。
爆炸是 100% 可重现的,但我从未设法制作一个简单的测试用例。大多数情况下它实际上并没有使编译器崩溃,您通常会收到一个与问题无关的错误,并且可能有数百行。环境不稳定,保存退出就OK了但是别想干别的了。
回到使用 Borland Pascal 7(最后一个 dos 版本)的石器时代,我多次破坏它。没有崩溃,只是不正确和不一致的代码发射。我终于学会了将 .EXE(不包括调试信息)保持在 3mb 以下。我走得越远,它就越不稳定。
我已经多次使 VC++ 崩溃,通常是使用模板代码。但这还不是最有趣的崩溃……
我使用 /analyze 选项编译了我的共享代码库,该编译器在没有开关的情况下编译时没有错误,并且在使用和不使用开关的 VS2008 上使 VS2005 Team System 编译器崩溃。当然 MS 不是很感兴趣,因为它是旧版本编译器中的一个错误,但我认为这很有趣。
我设法对 Python 解释器进行了段错误。当然,当时我正在开发一个 C 扩展,但它并不完全正确。
它不像以前那样发生了,但偶尔 ASP.net 预编译器会出现问题——我个人没有见过,但我已经在另一个项目上解决了一个问题,一旦它们发生名称冲突,因为它们不是在预编译期间正确使用命名空间(导致编译器崩溃)。
在过去的美好时光(非托管 MSVC++),我们有奇怪的编译器崩溃,通常是由于外部静态 win32 类 (.lib) 中的链接和一些奇怪的代码位偶尔会导致问题,但这些都很快得到了解决。
我不知道我是否会称之为崩溃,但 sdcc(小型设备 C 编译器)无法编译以特定方式形成的代码:
预处理器宏展开,生成扁平但大的代码 - main() 中的所有内容;执行跳过启动代码(设置堆栈等)并从 main() 的开头开始
这个答案的相关部分:
有时,sdcc 会拒绝编译语法正确的代码,并显示有关内存不足的消息。这甚至发生在具有 8GB RAM 的 64 位机器上编译。
在这些情况下,解决方案是将固件拆分为单独的部分,分别编译并分别执行。这些碎片可能已经能够重新连接在一起,但在那一点上并不重要。
我没有尝试过,但Keil 8051 编译器可能已经处理了有问题的代码。
我已经成功使 F# 编译器崩溃了很多次;但这不公平,因为它是一个 beta/alpha/research/etc 编译器。
我从来没有尝试过让编译器崩溃,但是 VB 编译器/调试器每天都会在我身上出现好几次。即使它是VB,这也算吗?
我的团队经常在我们的构建机器上使用 csharp 编译器出现随机的内部编译器错误。我们通过清理每个目标构建之间的所有 bin/obj 文件夹解决了这个问题。
我在为 Source 引擎编译地图时崩溃了 VVIS 。
这算不算?
A long time ago, I worked on COBOL on a Control Data computer. (If that sounds funny, it is. Control Data was known for its high-performance scientific computing systems, and the COBOL compiler was a bit of an afterthought.) I don't remember the details, but I had a program I was trying to port to a newer version. I tried things several different ways, and found out I had a choice between crashing the compiler or putting it into an infinite loop.
Not the compiler, but the linker in Visual Studio 2008 crashes several times per day for me under Windows 7 64 bit. Immediately building again always works without a crash. Microsoft don't seem to care...
Not really an answer to your question because it's not the code itself causing it, but I'm always willing to rant about this particular issue :-)
Template support in GCC 2.95 (though I might be misremembering the version) was buggy. Various constructs would cause it to crash. I can't find the test case, but I think inner classes of templates (or inner classes that were templates) were one way of getting an compiler error.
I had something more interesting: Linker internal error...
Do you know how to cause THAT?
I once wrote a C program that would make the computer spontaneously reboot. One downside is that it didn't really have anything to do with mergesort which I was trying to implement at the time.
Fortunately it went away once I'd gotten my pointer errors figured out.