Насколько важно устранить утечки памяти?

Я обнаружил, Valgring, что некоторые программы GTK + утечки памяти. Насколько важно устранить эти утечки? Я имею в виду, что часто эти программы работают очень хорошо, но, с другой стороны, никогда нельзя быть уверенным, если кто-то захочет скопировать часть кода утечки в какую-то другую программу. И я не уверен, что идея GTK + -программ состоит в том, чтобы работать быстро и, следовательно, есть утечки.

Поэтому, если я иногда обнаруживаю утечку памяти в программе с открытым исходным кодом, я должен ее исправить или есть, например, проблемы с эффективностью, и, следовательно, первоначальная идея программистов заключалась в том, чтобы написать небольшой небольшой утечка кода?

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

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

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

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

Мой совет - подать ошибку в трекере с предложенным исправлением, если лидеру все равно, он исправит это.

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

По моему общепризнанному догматическому мнению по этому вопросу, нет никаких оправданий физическим утечкам, по крайней мере, в любой библиотеке, которая стремится быть широко применимой. Так что я буду стремиться к ошибкам разработчиков GTK +, пока они сами не исправят это.

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

Даже самая ленивая программа, которая просто хочет выделить кучу маленьких кусочков памяти, может использовать простой последовательный распределитель, который просто удаляет всю память при завершении работы. Если распределитель даже не хочет иметь дело с выравниванием, он может просто заполнить каждый отдельный кусок, который он объединяет, до максимальных границ выравнивания. Если бы он смог выиграть с более быстрым временем выключения, не освобождая все эти крошечные куски памяти по отдельности, он также выиграет симметрично в обмен на тривиальные усилия, используя такой последовательный распределитель, который объединяет память в прямом последовательном режиме с гораздо быстрее, чем распределениеmallocи более дружественные к кешу шаблоны памяти, только чтобы все большие блоки непрерывной памяти, объединенные распределителем, были освобождены, когда библиотека будет готова. Вся библиотека должна сделать, это заменить их mallocвызовы , на которые они не удосужились freeчто - то вроде seq_malloc, и вызов seq_purgeв функции atexitобратного вызова , чтобы освободить всю память , выделенную при выгрузке.

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

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

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

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