2010-07-23 2 views
11

Моя программа (текстовый браузер) динамически выделяет память.Должен ли я освободить выделенную память при ненормальном завершении?

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

Теперь, что я делаю не do освобождает память перед аномальным завершением. (В настоящее время моя программа завершается сигналами и после сбоев mallocs/reallocs.)

Мой вопрос: вы считаете этот плохой стиль? Должен ли я освобождаться от аномального прекращения?

+0

Ваша система восстановит память, когда ваш процесс завершится, не так ли? –

ответ

12

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

4

На мой взгляд, освобождение памяти при сбое не требуется. Когда ваш процесс завершится, ОС вернет память, поэтому все, что вам нужно сделать, это выйти.

С другой стороны, другие ресурсы (например, открытые файлы) должны быть закрыты или, по крайней мере, сброшены - если нет, они не могут быть сохранены/сохранены неполными из-за буферизации.

0

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

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

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

Советую проверять всю память, выполненную до и после аномальных сценариев завершения.

0

Только в том случае, если ваша ОС не восстанавливает память при завершении программы. DOS и его «липкая память» - пример такой ОС. На большинстве современных ОС не бесплатно() при ненормальном завершении не является проблемой.

+0

какая память DOS не восстанавливает при завершении программы? – unbeli

+0

Hrm. Вы уверены, что это правда? – Gian

+0

Я уверен, что это правда, по крайней мере, для одного варианта MSDOS и BDOS CP/M - у них была поддержка того, что называлось «липкой памятью», которую программа могла бы распределять по пространству и оставалась выделенной даже после ее завершения. Кроме того, вызов TSR в MSDOS достиг чего-то подобного, но я бы не стал считать это аномальным завершением. –

0

Нет, если ваша программа всегда заканчивается ненормально. :) В любом случае ОС отлично справляется с задачей. На самом деле многие ленивые программисты даже не утруждают себя нормальным завершением, но это затрудняет обнаружение других утечек памяти (те, которые являются реальной проблемой).

3

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

Если ваша программа прерывается ненормально, в зависимости от причины, вы можете обнаружить, что вы не можете свободной памяти. Например, SIGSEGV, возникающий из-за испорченной кучи, означает, что даже попытка освободить другие вещи в куче может быть безнадежным упражнением.

0

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

Смежные вопросы