Наскільки важливо виправити витоки пам'яті?

Valgring виявив, що деякі програми GTK + просочують пам'ять. Наскільки важливо виправити ці витоки? Я маю на увазі, часто ці програми працюють дуже добре, але з іншого боку, ніколи не можна бути впевненим, чи хочеться скопіювати частину коду, що витікає, до якоїсь іншої програми. І я не впевнений, чи ідея GTK + -програм працювати швидко і тому є витоки.

Тож якщо я іноді знаходжу витік пам’яті у програмі з відкритим кодом, чи варто це виправити чи є, наприклад, проблеми з ефективністю, і тому початковій ідеєю програмістів було написати якийсь невеликий протікаючий код?

Наскільки важливо виправити витоки пам’яті, залежить від гостроти проблеми і що ще потрібно зробити, що важливо. Мій досвід полягає в тому, що невеликі витоки пам'яті, як правило, є досить доброякісними для більшості програм. Час роботи сеансу настільних додатків зазвичай не є достатньо довгим, щоб побачити будь-яке погіршення від невеликого витоку пам'яті.

Якщо ви пишете сервер, який працює цілодобово, то невеликі витоки пам’яті можуть накопичитися з часом і стати головною проблемою. Але тому багато компаній планують щодня або щотижня перезапускати свої сервери. Намагання знайти витоки пам’яті часто надмірно залежать від того, що може бути отримано, тому простіше регулярно перезапускати сервери та переходити до більш важливих речей.

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

Однак, якщо короткий біг є відносним, витік може вийти з-під контролю за кілька годин або накопичитися тижнями непомітно.

Моя порада - подати помилку в трекер із запропонованим виправленням, якщо ведучий піклується, він це виправить.

Тип протікання також важливий. Можливо, що виділення, яке протікає, - це одноразове виділення, де розробник навмисно покладався на ОС для очищення. Це дасть помилковий позитив на valgrind.

На мій догматичний погляд з цього приводу, в жодній бібліотеці, яка має на меті бути широко застосовною, немає виправдань для фізичних витоків. Тому я б прагнув помилитися з розробниками GTK +, поки вони самі їх не виправлять.

Досить тривіально, щоб бібліотека зареєструвала atexitзворотні дзвінки, щоб звільнити будь-яку пам'ять, яку вона виділяє, принаймні після завантаження. Якщо він хоче уникнути витрат суднових асигнувань, не слід робити це в першу чергу.

Навіть найлініша програма, яка просто хоче виділити навантажений човном шматок пам'яті відразу, може використовувати прямий послідовний розподільник, який просто очищає всю пам'ять при відключенні. Якщо алокатор навіть не хоче мати справу з вирівнюванням, він може просто прокладати кожен окремий фрагмент, який об'єднується до максимальних меж вирівнювання. Якщо йому вдалося скористатися швидшими часом відключення, не звільняючи всі ці підліткові шматки пам’яті окремо, це також виграє багато симетрично в обмін на тривіальні зусилля, використовуючи такий послідовний розподільник, який об'єднує пам’ять прямо-таки послідовно набагато швидші асигнування, ніжmallocі більше зручних для кешу шаблонів пам’яті, лише щоб звільнити всі великі блоки суміжної пам’яті, об'єднані алокатором, коли бібліотека створена. Тоді все, що потрібно зробити, - це замінити свої mallocдзвінки, на які вони не турбуються, freeчимось подібним seq_malloc, і зателефонувати seq_purgeв atexitзворотному дзвінку , щоб звільнити всю пам'ять, виділену після завантаження.

В іншому випадку у вас ця неприємна бібліотека захаращується повідомленнями у ваших інструментах виявлення витоку пам’яті, які вам зараз доведеться відфільтрувати. Гірше, якщо ви не систематично їх фільтруєте, вони можуть приховати витоки у вашій власній програмі, і ваші колеги можуть розвинути звичку їх переглядати, знижуючи в першу чергу корисність інструментів виявлення витоків у запобіганні власній команді від натискання на протікає код. Це жорстоко і некрасиво, і більше за все я не знаходжу аргументів на користь того, щоб робити це навмисно, щоб переконатись на всіх, враховуючи, наскільки тривіальним є використання рішення вище.

Логічні витоки (більш складний вид, від якого навіть сміття не може захистити) є складнішим питанням, і там я міг би знайти певне виправдання для короткочасних програм, щоб мати логічні витоки, якщо вони очищають всю пам'ять, яку вони виділили відключення, оскільки воно потребує великої думки щодо управління ресурсами, щоб уникнути логічних витоків (можливо, тим більше в мовах, на яких є GC). Але я не знаходжу жодного розумного приводу, щоб уникнути фізичних витоків, враховуючи, наскільки тривіальними вони є, щоб уникнути навіть у самих ледачих контекстах.

У всякому разі, я, як мінімум, відфільтрував би течі на вальгринд, щоб вони принаймні не псувалися зі здатністю вашої команди помітити вашу власну.

FWIW, якщо користувач повідомив про витік у додатку, над яким я працюю, я б дуже схильний виправити це (особливо якщо вони включили код для виправлення у звіті про помилку!). Однак це може статися не відразу, якщо витік був невеликим, а інші проблеми були більш гострими (скажімо, неполадки, що трапляються часто). Але я б напевно оцінив це і попрацював би це врешті виправити. Ви обов'язково повинні повідомити їх. Вони або оцінять це, і попрацюють, щоб виправити це (швидше за все), або їм не буде байдуже, і все це коштуватиме вам деякий час.