Другие ответы довольно хорошо охватили сторону ПК.Я коснусь некоторых проблем во встроенном мире.
Встраиваемый код имеет нечто похожее на segfault.Код хранится в каком-то энергонезависимом хранилище (обычно в наши дни флеш-память, но в прошлом - какое-то ПЗУ или ПЗУ).Запись этого требует специальных операций для его настройки;нормальные обращения к памяти могут читать из него, но не записывать в него.Кроме того, встроенные процессоры обычно имеют большие пробелы в своих картах памяти.Если процессор получает запрос на запись в память, доступную только для чтения, или если он получает запрос на чтение или запись для адреса, который физически не существует, процессор обычно выдает аппаратное исключение.Если у вас подключен отладчик, вы можете проверить состояние системы, чтобы найти, что пошло не так, как в случае с дампом ядра.
Нет никакой гарантии, что это произойдет при переполнении стека.Стек может быть размещен в любом месте в ОЗУ, и это обычно будет рядом с другими переменными.Результатом переполнения стека обычно является повреждение этих переменных.
Если ваше приложение также использует кучу (динамическое выделение), то обычно назначается раздел памяти, где стек начинается в нижней части этого раздела, ирасширяется вверх, и куча начинается в верхней части этого раздела и расширяется вниз.Ясно, что это означает, что динамически распределенные данные будут первой жертвой.
Если вам не повезло, вы можете даже не заметить, когда это произойдет, и тогда вам нужно выяснить, почему ваш код работает неправильно.В самом ироническом случае, если перезаписываемые данные являются указателями, вы все равно можете получить аппаратное исключение, когда указатель пытается получить доступ к недопустимой памяти - но это будет через некоторое время после переполнения стека, и естественным предположением будет то, чтоошибка в вашем коде.
Внедренный код имеет общий шаблон для решения этой проблемы, который заключается в «водяном знаке» стека путем инициализации каждого байта известным значением.Иногда компилятор может сделать это;или иногда вам может понадобиться реализовать это самостоятельно в коде запуска перед main ().Вы можете оглянуться назад с конца стека, чтобы найти, где оно больше не установлено в это значение, и в этот момент вы знаете верхний предел использования стека;или если все неверно, значит, вы переполнены.Встраиваемые приложения обычно (и эффективная практика) постоянно опрашивают это как фоновую операцию и сообщают об этом в диагностических целях.
После того, как стало возможным отслеживать использование стека, большинство компаний установитдопустимый запас в худшем случае, чтобы избежать переполнения.Обычно это где-то от 75% до 90%, но всегда будет запасной.Это не только позволяет предположить, что существует худший наихудший случай, которого вы еще не видели, но также облегчает жизнь для будущей разработки, когда необходимо добавить новый код, который использует больше стека.