Действительно ли я должен освободить выделенную память на аварийном завершении?
Моя программа (веб-браузер текстового режима) динамично выделяет память.
Я действительно освобождаю ненужные блоки во время времени выполнения, конечно. И я действительно освобождаю все перед нормальным завершением - так, чтобы средства проверки утечки памяти не давали мне ложные положительные стороны (и быть гибким должно основные рефакторинги когда-либо становиться необходимыми).
Теперь, то, что я не делаю, освобождает память перед аварийным завершением. (В настоящее время моя программа завершается на сигналах и, после того, как отказавший mallocs/reallocs.)
Мой вопрос: Вы рассматриваете этот плохой стиль? Действительно ли я должен освободить на аварийном завершении?
7 ответов
Нет. Я думаю, что вполне допустимо просто опустить руки и позволить ОС вернуть память после завершения программы. Я думаю, что если это действительно ненормальная ситуация и намерение состоит в том, чтобы программа завершилась, то хорошо ведущая себя программа должна просто очистить все дисковые ресурсы/блокировки и выйти как можно быстрее.
Вам не нужно возвращать память при нормальном завершении, кроме как для исключения ложных срабатываний в инструментах обнаружения утечек.
Если ваша программа завершается ненормально, в зависимости от причины, вы можете обнаружить, что не можете освободить память. Например, SIGSEGV, вызванный повреждением кучи, означает, что даже попытка освободить другой материал на куче может оказаться безнадежным занятием.
Только если ваша ОС не возвращает память при завершении программы. DOS и ее "липкая память" - пример такой ОС. В большинстве современных ОС отсутствие функции free()'ing при аварийном завершении программы не является проблемой.
Аномальное завершение процесса не приводят к блокам памяти, которые не могут использоваться другими процессами (фактически означает, что они свободны), если они были выделены им.
Мы выделяем / освобождаем память с помощью директив ОС, чтобы операционная система без ошибок отслеживала фрагменты памяти для каждого процесса и переводила их в непрерывное пространство виртуальной памяти. В случае смерти процесса загрузчик ОС сигнализирует об этом, и вся память отзывается. Ситуация усложняется, когда процессы разделяют память.
Пиринговые процессы, если они не созданы / запущены / разветвлены вашим процессом (например, рассмотрим внешний компонент, обслуживающий множество процессов для доступа к мультимедийным ресурсам), могли создать память (например, буфер) для обслуживания вашего процесса. В зависимости от политики владения этими внешними компонентами, эта память может не освободиться после смерти обслуживаемого процесса.
Я советую вам попробовать проверить всю память, зафиксированную до и после сценариев аварийного завершения.
Нет, если только ваша программа не завершается всегда ненормально. :) В любом случае, ОС прекрасно справляется с освобождением памяти. На самом деле многие ленивые программисты даже не утруждают себя освобождением памяти при нормальном завершении - но это затрудняет обнаружение других утечек памяти (тех, которые являются реальной проблемой).
На мой взгляд, освобождение памяти при сбое не требуется. Когда ваш процесс завершится, ОС освободит память, поэтому все, что вам нужно сделать, это выйти.
С другой стороны, другие ресурсы (например, открытые файлы) должны быть закрыты или, по крайней мере, очищены - в противном случае они не могут быть сохранены / сохранены неполными из-за буферизации.
При аварийном завершении вы хотите выполнять как можно меньше обработки. Сведение к минимуму возни с процессом прерывания будет означать, что вы сможете максимально приблизиться к причине прерывания, и любая дальнейшая обработка может рассматриваться как «загрязнение» процесса, что затрудняет отладку.