你曾經墜毀過編譯器嗎？

Question

每個人（至少每個使用編譯語言的人）都遇到了編譯錯誤，但是實際上碰到了多少次編譯器？

我已經有我的公平份額「內部編譯器錯誤」但大多數只是通過重新編譯而消失。你有（最小的）一段代碼會使編譯器崩潰嗎？

Answer 1

我編寫我們使用的編譯器，所以它有時會崩潰。

Answer 2

是的，特別是當它是一箇舊的或不足的編譯器（GCC 2.95，在C++模式下的Tendra）。不過，我不保留這些代碼。

Answer 3

當編譯C++時，如果模板使用情況混亂（例如，在關閉「>」時丟失），VC++已經崩潰了。

Answer 4

我見過C＃編譯器中的一些編譯器錯誤（所有邊界情況，都適當報告）並確認了其他人引發的一些崩潰。

我遇到的最恐怖的編譯器（一類）錯誤是一個Java版本中的JIT錯誤。這是相當可重複的，但導致虛擬機失敗。添加一個相當不可操作的語句（我不記得正確的東西 - 可能只是用一個初始值聲明一個額外的本地變量）將它從它碰巧遇到的任何角落移開 - 並且它在更高版本中得到修復。

Answer 5

我做到了。一些德爾福版本（讓我們說＃4）經常出現晦澀的錯誤信息。

較新的版本（2006年和更多）是穩定的，但不穩固。 （在這種情況下7是很棒的）。

編譯器崩潰通常發生在大量編輯和調試複雜項目（大量dll）的會話中。大多數情況下，重新啓動ide就足夠了。但有時你需要重新啓動電腦。

因爲交換文件變得太大，所以我和OS2一起崩潰了OS2。

Answer 6

的Actionscript 3.0：

switch(on_some_variable) 
{ 
} 

空開關= KABOOM！

Answer 7

Visual C++ 5.'Nuff說。

Answer 8

容易。

// -*- 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 9

VC擺好現在抓住這一點，但在90年代中期，這將墜毀於Microsoft C++和Borland C++編譯器：

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


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

的重載操作符 - >在本質上是遞歸的。該函數預期會返回一個指針，該指針再次應用於該操作符。該片段使代碼生成無限遞歸。

Answer 10

有一次，我使用Python文檔中的生成器示例，它打破了我們使用的Python版本。同一周，我的一個同事設法濫用FFI，因此任何涉及數字3的計算都會使python崩潰。

Answer 11

在我工作的一個項目中，Boost Lambda表達式的某些特定用法可能會導致Visual C++編譯器崩潰。（我們使用Visual Studio 2003）
編譯器只會在發佈版本中崩潰，調試版本可以正常工作。

在團隊中發生了一場關於適當使用lambda庫的宗教戰爭，我幾乎感謝編譯器爲我們解決了這個問題。 :-)

Answer 12

我還沒有做出GHC（Haskell編譯器）墜毀，但是我已經得到了它與一個

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

這是很容易解決錯誤了，除非你有一些棘手的（通常是錯誤的）設計，否則你不會觸及它，但它可能會成爲最好的編譯器錯誤消息。

Answer 13

Microsoft Xbox 360編譯器很容易崩潰。我獲得了日文評論的源代碼，當轉換爲普通文本時，該行最後一個字符中的一個是'\'，因此它將評論延續到下一行。如果下一行是切換命令，則編譯器崩潰。

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

Answer 14

在Mono C＃編譯器的1.2.x版本中，如果我沒有記錯，嵌套的匿名代理會崩潰很多。幸運的是，在2.x版本中，我沒有看到任何崩潰。

Answer 15

在我之前的工作中，我們有一個模擬器，它因能夠崩潰（ICE）編譯器或導致它們生成不正確的代碼而臭名昭着。當代碼實際上正確生成時，編譯器花了15分鐘來處理單個源文件。 Visual Studio從來沒有（只要我在那裏工作）能夠編譯模擬器核心。

核心是從DSL自動生成的，生成的代碼通常會將編譯器推到極限。

升級到新版本的GCC通常會引起廣泛的不安：新版本會工作嗎？

Answer 16

我已經崩潰了Delphi 7多次，要求它編譯遺留的dos代碼。

最主要的罪魁禍首似乎是在系統單元中的任何資格。這並不總是讓人失望，但當它暴露在這些東西上時，我會翻閱並重寫任何需要這種重寫的東西，問題就會消失。

爆炸是100％可重現的，但我從來沒有設法做出一個簡單的測試用例。它實際上並沒有在大多數時候崩潰編譯器，你通常會得到一個與該問題無關的錯誤，並且可能有數百條錯誤。環境不穩定，保存和退出是好的，但不要想到做其他事情。

回到石器時代，Borland Pascal 7（最後的dos版本）我打破了很多次。沒有崩潰，只是不正確和不一致的代碼發射。我終於學會了將.EXE（不包括調試信息）保持在3mb以下。我走得越遠，它就越不穩定。

Answer 17

我已經崩潰了VC++多次，通常使用模板代碼。但這不是最有趣的崩潰...

我崩潰VS2005團隊系統編譯器與/分析選項編譯我的共享代碼庫，沒有錯誤編譯沒有錯誤，沒有開關，並在VS2008有和沒有開關。當然，MS並不是很感興趣，因爲這是舊版本編譯器中的一個bug，但我認爲它非常有趣。

Answer 18

這墜毀C64 BASIC：

PRINT 0 + "" +- 0 

Answer 19

的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 20

那麼，這實際上並沒有崩潰，編譯器 - - 這只是一個錯誤，VC++不會接受完美的代碼。 （details provided here）。

奇怪的是，它只有在三個相當模糊的條件都滿足時纔會觸發。只需移動一行代碼即可實現有效的解決方法。而其中一個必要的先決條件是「使用命名空間標準;」這在生產代碼中廣泛受到阻礙。

不過，詢問如何解決問題的消息是Microsoft VC++新聞組的主要內容。我無法弄清楚這麼多人偶然發現了一個晦澀的bug。最終，我問了一個人......

觸發錯誤所需的確切代碼是Stroustrup的「The C++ Programming Langauge」中的一個示例。 （*）

（*）注意，我並不是說他故意這樣做。我確信他在C++的UNIX變體下進行了測試，並且完全沒有意識到它對VC++的影響。

Answer 21

感謝@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 22

我設法segvere Python解釋器。當然，我當時正在研究C擴展，並且認爲它不太對。

Answer 23

糟糕，忘記了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 24

它不會發生，因爲它曾經爲多，但偶爾ASP.net預編譯器有問題 - 我還沒有看到它親自出馬，而是因爲那裏有我曾經固定在另一個項目中的一個問題名稱會發生​​衝突，因爲它們在預編譯期間沒有正確使用名稱空間（導致編譯器崩潰）。

在過去的美好日子（非託管MSVC++）中，我們發生了奇怪的編譯器崩潰，通常是由於在外部靜態win32類（.lib）中連接了一些奇怪的代碼偶爾導致了問題，但是這些都被拾取很快。

Answer 25

我已經崩潰了一個編譯器之前運行它內存不足。

給一個DOS編譯器大約0.5mb的源代碼。緊縮。

Answer 26

我不知道我是否願意稱之爲崩潰，但SDCC（Small Device C Compiler）未能在形成一種特殊的方式編譯代碼：

• 目標：8051
• 代碼必須在512執行從外部測試器加載的字節緩存
• 測試程序處於控制狀態並存儲代碼 - 緩存無法讀取下一頁
• 未允許函數調用 - PC（程序計數器）將跳至未駐留在緩存中的位置;預處理器宏用於完成模塊化編碼練習
• 跳躍（分支），如果它不跳過緩存
• 沒有常量值 - 在程序代碼的數據部分，導致緩存中的代碼獲取的東西不在高速緩存中 - 預處理器常量（#define）這裏確定

預處理器宏被展開，導致平坦但大型代碼 - main（）中的所有內容。執行跳過啓動代碼（設立棧等），在main（）的

這個答案的相關部分的開頭開始：

偶爾，SDCC會拒絕編譯語法正確的代碼，用關於耗盡內存的消息。這甚至發生在具有8GB RAM的64位盒子上編譯。

這些情況下的解決方案是將固件分成單獨的部分並分別編譯並分別執行。這些作品可能已經能夠被連接在一起，但在那個時候它並不重要。

我沒有嘗試，但Keil 8051編譯器可能可以處理有問題的代碼。

Answer 27

我設法讓F＃編譯器崩潰了很多次;但這不公平，因爲它是一個beta/alpha/research/etc編譯器。

Answer 28

當你得到一個消息「災難性失敗」你知道你想....

邁克爾

Answer 29

我從來沒有嘗試過向崩潰的編譯器，但VB編譯器/調試器我每天都會出去好幾次。即使它是VB，這是否算數？

Answer 30

我們的團隊在構建機器上經常伴隨着csharp編譯器的隨機內部編譯器錯誤。我們通過清除每個目標的構建之間的所有bin/obj文件夾來解決該問題。

Answer 31

編譯源引擎的映射時，我崩潰了VVIS。

這算不算？

Answer 32

今天VS2003SP1給了我一個抱怨編譯器文件'msc1的C1001（內部編譯器錯誤）。CPP」，行2708）因爲這樣：

struct 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 33

很久以前，我曾在一個COBOL控制數據的計算機上。 （如果這聽起來很有趣，那就是Control Data以其高性能的科學計算系統而聞名，COBOL編譯器有點事後考慮）。我不記得細節，但我有一個程序，我試圖以移植到更新的版本。我嘗試了幾種不同的方式，發現我可以在編譯器崩潰或進入無限循環之間作出選擇。

Answer 34

我使用pcc和gcc編譯我的舊OS項目。

我發現一個pcc和gcc如何處理一個不平凡的代碼片段並且它崩潰pcc的錯誤。 （字符是我的平臺上簽字）

struct{ 
    char myvalue:1; 
}mystruct; 

PCC崩潰，因爲所有位字段值必須是int了，所以它真的更馬車那裏，但GCC處理錯誤的話。看，如果你仔細想一想，它就會被簽名，但只有一點空間。因此，它只能存儲0和-1。那麼，海灣合作委員會通過存儲0或1來處理它錯誤。

Answer 35

不是編譯器，但在Visual Studio 2008中的鏈接器在Windows 7 64位下每天崩潰幾次。立即再次建設總是沒有崩潰的工作。微軟似乎並不關心......

不是一個真正的回答你的問題，因爲它本身不是導致它的代碼，但我總是願意咆哮關於這個具體問題:-)

Answer 36

模板GCC 2.95支持（儘管我可能會誤解版本）是buggy。各種構造會導致它崩潰。我找不到測試用例，但我認爲模板的內部類（或內部類是模板）是獲得編譯器錯誤的一種方式。

Answer 37

我有更有趣的東西： 鏈接器內部錯誤......

你知道如何引起的？

Answer 38

這是一種崩潰VS2003 C++編譯器的方法。

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

這將導致崩潰與以下錯誤消息

致命錯誤C1001：內部編譯 錯誤（編譯器文件「msc1.cpp」，行 2708）請選擇技術 支持命令在Visual C++幫助 菜單上，或打開技術支持 幫助文件以獲取更多信息

在Tmap（定義爲m_map的第二行）後立即刪除分號以消除錯誤。

Answer 39

我曾經寫過一個C程序，使計算機自發重啓。其中一個缺點是它與我當時試圖實施的mergesort沒有任何關係。

幸運的是，一旦我弄錯了我的指針錯誤，它就消失了。