Каждый (по крайней мере, каждый, кто использует скомпилированный язык) сталкивается с ошибками компиляции, но сколько раз вы получаете, чтобы на самом деле скомпрометировать компилятор?
У меня была справедливая доля внутренних ошибок компилятора ", но большинство ушло просто путем повторной компиляции. У вас есть (минимальная) часть кода, которая приводит к сбою компилятора?
Я пишу компилятор, который мы используем, поэтому он иногда падает.
легко.
// -*- C++ -*-
template <int n>
class Foo : public Foo<n+1>
{
};
int main(int, char*[])
{
Foo<0> x;
return 0;
};
[email protected]:~/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 С++ и Borland С++:
struct MyClass
{
MyClass operator->() { return *this; }
};
int main(int argc, char* argv[])
{
MyClass A;
A->x;
}
Перегруженный оператор → является внутренне рекурсивным. Ожидается, что функция вернет указатель, к которому oper- > снова применяется. Этот фрагмент сделал бесконечное рекурсивное генерирование кода.
ActionScript 3.0:
switch(on_some_variable)
{
}
Пустой переключатель = Kaboom!
Visual С++ 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 ==========
Ну, на самом деле это не привело к сбою компилятора. Это была просто ошибка, когда VС++ не принимал совершенно хороший код. (подробности здесь).
Нечетным это было то, что это было вызвано только тогда, когда были встречены три довольно неясные условия. Перемещение одной строки кода было всем, что было необходимо для эффективного обходного пути. И одним из необходимых предварительных условий было "использование пространства имен std"; который широко обескуражен в производственном коде.
Тем не менее сообщения о том, как устранить проблему, были основным продуктом для групп новостей Microsoft VС++. Я не мог понять, как многие люди наткнулись на непонятную ошибку. Итак, в конце концов, я спросил кого-то.....
Точный код, необходимый для запуска ошибки, был примером в Struustrup "Программирование Langauge" на С++. (*)
(*) Заметьте, я не говорю, что он сделал это нарочно. Я уверен, что он протестировал его в UNIX-варианте С++ и совершенно не знал об этом влиянии на VС++.
Я видел несколько компиляторов в компиляторе С# (все крайние случаи, все сообщается соответственно) и подтвердили некоторые сбои, вызванные другими людьми.
Самый страшный компилятор (из рода), с которым я столкнулся, был ошибкой JIT в одной версии Java. Он был вполне воспроизводимым, но заставил виртуальную машину спуститься вниз. Добавление оператора довольно-не-op (я не могу точно помнить, что из-за этого - возможно, просто объявляя дополнительную локальную переменную с начальным значением) удалил ее из любого угла, к которому это случилось, - и оно было исправлено в более поздней версии.
Это разбило C64 BASIC:
PRINT 0 + "" +- 0
Да, особенно когда это старый или недоработанный компилятор (GCC 2.95, Tendra в режиме С++). Тем не менее, я не сохраняю фрагменты кода.
Visual С++ 5. 'Нафф сказал:
Ой, забыл 'e' в typedef и разбил компилятор.
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
Сегодня VS2003SP1 дал мне C1001 (Internal Compiler Error), жалующийся на файл компилятора 'msc1.cpp', строка 2708) из-за этого:
struct PATTERN {
…
};
Оказывается, проблема заключалась в том, что имя структуры, которое я пытался определить (PATTERN), уже было типефидом в GDI для типа кисти. Однако вместо того, чтобы сказать мне, что символ уже определен (как это делается для большинства других вещей), он не только не указывал на структуру как проблему, я сузил проблему до нее, выборочно комментируя блоки до тех пор, пока ошибка не исчезла - но это также дало мне вышеупомянутую загадочную ошибку, которая не имеет ничего общего с указанным файлом, - который я даже не могу найти для изучения рассматриваемой строки.: |
Я смог воспроизвести его со следующим кодом:
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 +...
Здесь можно запустить компилятор VS2003 С++.
typedef map<int,int> Tmap;
private: Tmap; * m_map;
Это приведет к сбою и следующему сообщению об ошибке
фатальная ошибка C1001: ВНУТРЕННИЙ КОМПЬЮТЕР ERROR (файл компилятора 'msc1.cpp', строка 2708) Пожалуйста, выберите Технический Поддержка команды справки Visual С++ меню или откройте Техническую поддержку файл справки для получения дополнительной информации
Удалите точку с запятой сразу после Tmap (вторая строка, которая определяет m_map), чтобы устранить ошибку.
В проекте, в котором я работал, некоторые специальные применения Boost Lambda могут привести к сбою компилятора Visual С++. (Мы использовали Visual Studio 2003)
Компилятор только сбой во время сборки релиза, сборка отладки будет работать нормально.
В команде велась религиозная война, связанная с надлежащим использованием библиотек лямбды, я был почти благодарен за то, что компилятор уладил ее для нас.: -)
В версии 1.2.x компилятора Mono С# достаточно сложно скомпрометировать сложный код (если я правильно помню, вложенные анонимные делегаты). К счастью с выпуском 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.5 МБ исходного кода. Хруст.
Когда вы получаете сообщение "Катастрофическая неудача", вы знаете, что пытаетесь...
Майкл
Я использую как pcc, так и gcc для компиляции моего старого проекта ОС.
Я нашел ошибку в том, как и pcc и gcc обрабатывают нетривиальную часть кода, и он разбился на pcc. (символы подписаны на моей платформе)
struct{
char myvalue:1;
}mystruct;
pcc разбился, потому что все битовые значения должны быть int, хотя, поэтому он действительно более глючит, но gcc неправильно обрабатывает его. Смотрите, если вы думаете об этом, он подписан, но имеет только место для одного бита. Поэтому он может хранить только 0 и -1. Ну, gcc неправильно обрабатывает 0 или 1.
VС++ врезался во мне при компиляции С++, если использование шаблона перепутано (например, отсутствует при закрытии " > " ).
Я сделал. Некоторые версии Delphi (скажем, № 4) очень часто разбивались с загадочными сообщениями об ошибках.
Новые версии (2006 и более) стабильны, но не прочны. (7 в этом случае было здорово).
Сбой компилятора часто возникает при больших изменениях и отладочных сессиях сложных проектов (много DLL). В большинстве случаев достаточно повторного запуска идеи. Но иногда вам нужно перезагрузить ПК.
O и я однажды разбили OS2 вместе с компилятором, потому что swap файл стал слишком большим.
Однажды, когда я использовал пример генераторов из документов Python, он нарушил версию используемого нами Python. На той же неделе один из моих коллег сумел неправильно использовать FFI, чтобы любой расчет, связанный с номером 3, разбивал питон.
Компилятор Microsoft Xbox 360 может легко сработать. Мне дали исходный код с японскими комментариями, а при преобразовании в обычный текст одним из последних символов в строке был "\", поэтому он продолжал комментарий на следующую строку. Если следующая строка была командой switch, тогда компилятор сработает.
//wierd japanese characters here %^$$\
switch(n)
{
case 0:
.....
break;
case 1:
.....
break;
}
Я разбил Delphi 7 много раз, прося его скомпилировать старый код dos.
Главным виновником, по-видимому, является любая квалификация чего-то как находящегося в системном блоке. Это не всегда взорвется, но когда он взорвется на таком материале, я просматриваю и переписываю все, что требует такого переопределения, и проблема исчезает.
Разрушения на 100% воспроизводимы, но мне никогда не удавалось сделать простой тестовый пример. На самом деле это не приводит к сбою компилятора большую часть времени, вы обычно получаете ошибку, которая не имеет ничего общего с проблемой и может быть сотнями строк от нее. Окружающая среда дестабилизирована, сохранение и выход в порядке, но не думайте ничего делать.
Вернувшись в каменный век с Borland Pascal 7 (последняя версия dos), я много раз ее разбивал. Никакой сбой, только некорректная и непоследовательная эмиссия кода. Я, наконец, научился хранить .EXE(не считая информацию об отладке) ниже 3mb. Чем дальше, тем больше я стал более неустойчивым.
Я разбил VС++ несколько раз, обычно с кодом шаблона. Но это не самая интересная авария...
Я разбил компилятор Team Team VS2005 с параметром /analysis, скомпилировавшим мою общую библиотеку кодов, которая скомпилирована без ошибок без коммутатора, и на VS2008 с коммутатором и без него. Конечно, MS была не очень заинтересована, потому что это была ошибка в старой версии компилятора, но я подумал, что это довольно интересно.
Мне удалось перефразировать интерпретатор Python. Разумеется, в то время я работал над расширением C и получал его не совсем правильно.
Это происходит не так, как раньше, но изредка прекомпилятор ASP.net имеет проблемы - я не видел его лично, но я исправил проблему в другом проекте, когда они столкнулись с именами, потому что они не использовали пространства имен должным образом (вызвали сбои компилятора) во время предварительной компиляции.
В старые добрые времена (неуправляемый MSVС++) у нас был сбой нечетного компилятора, обычно из-за связи во внешних статических классах win32 (.lib), и несколько нечетных битов кода изредка вызывали проблемы, но все они были подняты очень быстро.
Я не знаю, могу ли я назвать это сбоем, но sdcc (Small Device C Compiler) не удалось скомпилировать код, сформированный в особым образом:
Макросы препроцессора разворачиваются, что приводит к плоскому, но большому коду - все в main(); выполнение пропускает код запуска (настройка стека и т.д.) и начинается с начала main()
Соответствующая часть этого ответа:
Иногда sdcc отказывается компилировать синтаксически корректный код с сообщением об исчерпании памяти. Это даже произошло с компиляцией в 64-битных блоках с 8 ГБ ОЗУ.
Решение в этих случаях заключалось в том, чтобы разбить прошивку на отдельные части и скомпилировать их отдельно и выполнить их отдельно. Возможно, части могли быть связаны друг с другом, но в этот момент это не имело значения.
Я не пробовал, но Keil компилятор 8051, вероятно, мог бы обработать проблемный код.