Насколько сильно может произойти сбой?

Question

Я часто слышал, что С может разбиться эффектно. Недавно я впервые почувствовал это, когда функция, которую я ожидал вернуть строку, вернула маленькие счастливые лица. С тех пор я был более осторожен с инициализацией указателей и неправильной памяти для массивов. Тем не менее, мне трудно поверить, что программа может аварийно завершить работу ...

Полагаю, это будет зависеть от объема программы? Я имею в виду, если ошибка в программе, которая имела дело с вашим поклонником, скопировала счастливые лица в какое-то важное место в памяти ...?

Мой вопрос: сколько существует мифов в мире зрелищных аварий C? Могу ли я получить конкретные примеры опасных вещей, которых следует избегать?

г.

Answer 1

• http://xkcd.com/371/
• http://blog.raamdev.com/category/technology/programming/cc
• http://en.wikipedia.org/wiki/Segmentation_fault

Answer 2

Я думаю, что в дни до виртуальной памяти, возможно, было еще хуже, когда вы могли очистить память других процессов, но в настоящее время самое худшее, что может произойти, это просто сбой вашей собственной программы. Обычно через ошибки сегментации от плохих указателей.

Это, конечно, исключает возможность взрыва из-за неправильного использования системных ресурсов - вы можете сделать это на любом языке.

Answer 3

Когда я учился программировать на C ++, это было на Mac с системой 7 или 8, я не помню, какая именно. В любом случае, у него не было защищенной виртуальной памяти, поэтому множество ошибок, таких как оставление висящего указателя или переполнение буфера, могли привести к сбою всего компьютера. Я помню, что когда Apple впервые объявила, что собирается создать новую ОС с защищенным пространством памяти на Macworld или чем-то еще, они показали исходный код программы:

while (true)
  *(int *)i++ = 1;

И когда они запустили программу, и только программа остановилась, а не вся машина (на ней было сообщение типа «Вам не нужно перезагружать компьютер»), вся комната, полная разработчиков, очевидно, разразилась аплодисментами. В любом случае, очевидно, что отсутствие защищенной памяти действительно усложнило программирование на C или C ++ из-за повышенной серьезности сбоя.

В настоящее время это не такая уж большая проблема, если вы не программируете что-то, что работает на уровне супервизора, у вас нет возможности аварийно завершить работу ОС.

Answer 4

Самое худшее, что случилось со мной, были повреждения памяти, которые не вызывали сбой сразу, но через некоторое время ... затрудняли его обнаружение .. argh

Answer 5

Операционная система предотвращает большинство ужасных проблем в наши дни. Худшее, что я когда-либо делал, это жесткая блокировка машины (просто пришлось перезагрузиться, удерживая нажатой кнопку питания) и зашифровать несколько файлов.

Все зависит от того, к каким ресурсам вы обращаетесь, на самом деле. Если вы пишете файлы, есть несколько способов запутать структуры каталогов, которые используются для запутывания системных утилит, но большинство из этих проблем были исправлены. Если вы делаете что-то от имени пользователя root, тогда вы можете сделать беспорядок, потому что многие другие системные файлы доступны для записи. Если вы используете сеть, есть много вещей, которые могут пойти не так, как надо, но не намного больше, чем использование слишком большой полосы пропускания. Конечно, несколько лет программирования, и вы увидите все виды невероятных вещей.

По большей части можно экспериментировать и играть. В наши дни системы достаточно устойчивы, и вы не сможете создать беспорядок, из которого слишком сложно выйти. Операционная система сохраняет каждую программу в своем собственном фрагменте памяти и запрещает доступ для изменения критически важных систем, если вы не являетесь администратором или пользователем root. Свисающий указатель вашего сорта может напечатать забавные вещи или привести к сбою вашей программы, но он не разрушит современный компьютер.

Из комментария в другом ответе: «Я использую Nintendo DS для их запуска»

Хорошо, это важно! (Во-первых: потрясающая идея! Звучит как веселье.) Кодирование для чего-то подобного не то же самое с точки зрения того, что может пойти не так, как большинство кодировок для настольного компьютера. Краткий взгляд на документацию по libnds и некоторые учебные пособия по программированию Nintendo DS показывает мне, что не существует ОС, о которой можно говорить. Итак, я понятия не имею, сколько вы могли бы сделать с блуждающим указателем, вероятно, много. Возможно, что-то разрушительное. Это может быть хорошей идеей для охоты на людей, которые раньше занимались программированием для этой платформы, посмотрите, что они скажут.

Answer 6

Вот небольшой фрагмент из «Десяти заповедей для программистов» Генри Спенсера:

• Заповедь № 2 - Не следуй указателю NULL, потому что хаос и безумие ждут тебя в конце.
• Очевидно, что Священные Писания были неправильно расшифрованы здесь, поскольку слова должны были быть `` нулевым указателем '', чтобы минимизировать путаницу между концепцией нулевых указателей и макросом NULL (которых больше всего). В противном случае смысл прост. Нулевой указатель указывает на области, заполненные драконами, демонами, дампами ядра и бесчисленным количеством других грязных существ, и все они радуются резвости в вашей программе, если вы нарушаете их сон. Нулевой указатель не указывает на 0 любого типа, несмотря на какой-то богохульный старый код, который безоговорочно предполагает это.

Для тех, кто не знаком с C, я думаю, что лучшее письменное краткое введение в C сделано в « Десять заповедей для программистов C (Аннотированное издание) » Генри Спенсером. То, как оно написано, действительно раскрывает читателю опасности С ... и в то же время смешно (а это значит, что читатель действительно будет уделять больше внимания).

=========================

Лично ... C не так плохо падает, когда вы занимаетесь разработкой десктопов , потому что у вас есть роскошь ошибки сегмента. Сег-сбой - это когда ОС видит, что вы ДЕЙСТВИТЕЛЬНО пытаетесь что-то вспомнить, и говорит «эй! Вас туда не пускают» и останавливает процесс.

Когда вы занимаетесь разработкой для встроенного C ... именно тогда вы получаете ДЕЙСТВИТЕЛЬНО захватывающие сумасшедшие вещи ... то есть они ТРЕБУЮТ вам включить-выключить 99,9% времени. Как в этот раз где код каким-то образом портит мой стек вызовов ... и затем вы выполняете какую-то другую случайную функцию ... и затем ISR каким-то образом продолжает работать ... и для исправления такой ошибки требуется 2 недели.

Answer 7

Что ж, если вы пишете код ядра, иногда вы можете перезаписывать критичные для системы биты памяти, такие как векторы прерываний, глобальные таблицы дескрипторов, таблицы процессов, вызывая всякие забавные вещи!

Answer 8

С само по себе ничего не может разбить. Неаккуратное программирование может привести к сбою.

«Счастливые лица» указывают на то, что ваш код испортил память. Единственное, что С связано с этим, это то, что вы решили использовать его. (И факт, что ваша ОС позволила этому случиться, удивителен - вы все еще используете версию DOS?)

Answer 9

В настоящее время довольно сложно заставить C аварийно завершить , что сложно (если вы не кодируете ядро ​​ОС или что-то в этом роде).

Еще в дни DOS / Win95 / Win98 вы могли сделать C-программу chash действительно, действительно плохо. Я имел обыкновение получать это много:

Всякий раз, когда у меня была опасная операция с указателем, связанная с памятью, я получал экран, основанный на символах, полный всевозможных символов, разных цветов, некоторые из них мигают !!! Я предполагаю, что операции каким-то образом испортились с видеопамятью.

Но сегодня, поскольку процессы выполняются в безопасных ядрах, худшее, что вы получите, если ваш процесс исчезнет.

Answer 10

до архитектуры защищенной памяти большинство векторов перехода, используемых операционной системой, хранились на нулевой странице памяти (адреса начинаются с нуля)

, поэтому запись в ячейки памяти на нулевой странице - это легко сделать с помощью указателей null / bad - изменит векторы переходов операционной системы, вызывая все виды странного поведения сбоя - все от заблокированных клавиатур и мигающих экранов видео, полных мусора на жесткий диск мигает безумие, синий экран смерти, перезагрузка и т. д.

[кодирование на ассемблере было еще веселее]