Seberapa penting untuk memperbaiki kebocoran memori?


19

Saya menemukan oleh Valgring bahwa beberapa program GTK + bocor memori. Seberapa penting untuk memperbaiki kebocoran itu? Maksud saya, seringkali program-program itu bekerja dengan sangat baik tetapi di sisi lain, orang tidak pernah bisa yakin jika seseorang ingin menyalin bagian dari kode yang bocor ke beberapa program lain. Dan saya tidak yakin apakah ide program GTK + adalah untuk bekerja dengan cepat dan karena itu ada kebocoran.

Jadi jika saya kadang-kadang menemukan kebocoran memori dalam program open source, haruskah saya memperbaikinya atau ada misalnya masalah efisiensi dan karena itu ide awal programmer adalah menulis beberapa kode bocor kecil?


17
Kebocoran memori selalu tidak diinginkan. Mereka mewakili sumber daya yang tidak dapat dimanfaatkan seluruh sistem, termasuk program host, hingga program berakhir.
recursion.ninja

Ada alat / pustaka yang memadai yang menangani pelacakan kebocoran memori. Ini sepadan dengan usaha, karena penggunaan API di pihak Anda mungkin salah.
Joop Eggen

1
Sebagai catatan - valgrind hebat tetapi dapat melaporkan beberapa positif palsu (saya pernah melihatnya di GObject).
Maciej Piechotka

Komputasi tergantung pada pemrosesan dan memori: yang pertama adalah kode, dan yang terakhir ruang yang digunakan. Jika Anda tidak bisa dipercaya untuk tidak mengacaukan kamar Anda sendiri, bagaimana mungkin Anda diharapkan menggunakannya untuk sesuatu yang bermanfaat?
imallett

1
"Selalu kode seolah-olah orang yang akhirnya mempertahankan kode Anda adalah seorang psikopat kejam yang tahu di mana Anda tinggal."
Jesse C. Slicer

Jawaban:


6

Seberapa penting untuk memperbaiki kebocoran memori tergantung pada tingkat keparahan masalah dan apa lagi yang harus Anda lakukan yang penting. Pengalaman saya adalah bahwa kebocoran memori kecil cenderung agak jinak untuk sebagian besar aplikasi. Seumur hidup sesi aplikasi desktop biasanya tidak cukup lama untuk melihat degradasi dari kebocoran memori kecil.

Jika Anda menulis server yang beroperasi 24/7, maka kebocoran memori kecil dapat bertambah seiring waktu dan menjadi masalah besar. Tapi itu sebabnya banyak perusahaan menjadwalkan server mereka untuk memulai kembali setiap hari atau setiap minggu. Upaya untuk menemukan kebocoran memori seringkali berlebihan dibandingkan dengan apa yang mungkin diperoleh, sehingga lebih mudah untuk me-restart server secara teratur dan beralih ke hal-hal yang lebih penting.


2
Saya tidak pernah bekerja di perusahaan yang me-restart server mereka setiap minggu ... bahkan kurang setiap hari. Saya setuju biaya untuk memperbaiki kebocoran mungkin tinggi untuk memperbaikinya tetapi memiliki pola pikir ini tidak baik IMO
Rémi

@ Rémi Kebanyakan, jika tidak semua, server game MMO melakukannya, biasanya setiap minggu.
Sjoerd

35

Untuk program yang berjalan singkat, kebocoran memori tidak sepenting; OS akan mengklaim kembali segala sesuatu pada terminasi, tetapi mereka dapat menyebabkan sumber daya lainnya tidak dirilis.

Namun berjalan singkat relatif, kebocoran dapat lepas kendali dalam beberapa jam atau menumpuk selama berminggu-minggu tanpa disadari.

Saran saya adalah untuk mengajukan bug di pelacak dengan perbaikan yang diusulkan, jika pemimpin peduli dia akan memperbaikinya.

Jenis kebocoran juga penting. Mungkin saja alokasi yang bocor adalah alokasi satu kali di mana dev dengan sengaja mengandalkan OS untuk pembersihan. Ini akan memberikan false positive pada valgrind.


4
Saya kebanyakan setuju. Namun saya menyarankan Anda menekankan pentingnya kebocoran memori. Kebocoran memori tidak dianggap enteng dan dapat menyebabkan beberapa "fitur" aplikasi Anda yang menarik.
Vladimir Kocjancic

@VladimirKocjancic: +1 untuk "feature"
Emilio Garavaglia

1
Saya hanya ingin menunjukkan bahwa komputer mampu melakukan pemrosesan satu-dalam-sejuta itu beberapa juta kali dengan cukup cepat. Jangan pernah lupakan itu. Jadi jika Anda memperhitungkannya maka saya setuju dengan jawaban ini, karena itu benar-benar tergantung pada program. Untuk sistem tertanam yang dimaksudkan untuk berjalan tanpa campur tangan manusia, kebocoran memori sangat mematikan. Untuk implementasi "grep" Anda mungkin tidak peduli.
Dunk

2
@Dunk: Tergantung: jika Anda grepmelalui file yang sangat besar dan program Anda bocor beberapa byte untuk setiap jalur input, Anda bisa kehabisan memori.
Giorgio

0

Menurut pendapat dogmatis yang saya akui tentang satu hal ini, tidak ada alasan untuk kebocoran fisik setidaknya di perpustakaan mana pun yang bertujuan diterapkan secara luas. Jadi saya akan mencoba untuk bug pengembang GTK + sampai mereka memperbaikinya sendiri.

Cukup sepele bagi perpustakaan untuk mendaftarkan atexitpanggilan balik untuk membebaskan memori apa pun yang dialokasikan setidaknya setelah dibongkar. Jika ia ingin menghindari biaya alokasi kapal yang sangat kecil, itu semestinya tidak dilakukan.

Bahkan program paling malas yang hanya ingin mengalokasikan satu kapal penuh memori yang sangat sedikit sekaligus dapat menggunakan pengalokasi sekuensial langsung yang hanya membersihkan semua memori pada saat shutdown. Jika pengalokasi bahkan tidak ingin berurusan dengan penyelarasan, itu hanya bisa pad setiap potongan itu dikumpulkan ke batas penyelarasan maksimum. Jika itu bisa mendapatkan keuntungan dengan waktu shutdown yang lebih cepat dengan tidak membebaskan semua potongan memori yang kecil secara individual, itu juga menguntungkan banyak secara simetris dengan imbalan upaya sepele dengan menggunakan pengalokasi sekuensial yang menyatukan memori dalam mode berurutan lurus dengan alokasi jauh lebih cepat daripadamallocdan lebih banyak pola memori yang ramah-cache, hanya untuk memiliki semua blok besar memori yang berdekatan dikumpulkan oleh pengalokasi dibebaskan ketika ketika perpustakaan dilakukan. Semua perpustakaan harus lakukan adalah mengganti mereka mallocpanggilan yang mereka tidak repot-repot untuk freedengan sesuatu seperti seq_malloc, dan panggilan seq_purgedalam atexitcallback untuk membebaskan semua memori yang dialokasikan pada diturunkan.

Kalau tidak Anda punya perpustakaan jahat ini mengacaukan pesan di alat deteksi kebocoran memori Anda, Anda sekarang harus menyaring. Lebih buruk lagi, jika Anda tidak secara sistematis menyaringnya, mereka dapat mengaburkan kebocoran dalam aplikasi Anda sendiri dan kolega Anda mungkin mengembangkan kebiasaan untuk menghadapinya, mengurangi kegunaan alat deteksi kebocoran di tempat pertama dalam mencegah tim Anda sendiri dari mendorong kode bocor. Itu kotor dan jelek dan yang paling penting saya tidak menemukan argumen yang mendukung melakukan ini sengaja menjadi menarik sama sekali mengingat betapa sepele untuk menggunakan solusi di atas.

Kebocoran logis (jenis yang lebih kompleks yang bahkan tidak dapat dilindungi oleh pengumpulan sampah) adalah masalah yang lebih kompleks, dan di sana saya dapat menemukan beberapa pembenaran untuk program jangka pendek untuk memiliki kebocoran logis selama mereka membersihkan semua memori yang mereka alokasikan pada shutdown karena itu memerlukan banyak pemikiran tentang manajemen sumber daya untuk menghindari kebocoran logis (bisa dibilang lebih dalam bahasa yang memiliki GC). Tapi saya tidak menemukan alasan yang masuk akal untuk menghindari kebocoran fisik mengingat betapa sepele mereka untuk menghindari bahkan dalam konteks yang paling malas.

Bagaimanapun, setidaknya saya akan menyaring kebocoran di valgrind sehingga mereka setidaknya tidak mengacaukan kemampuan tim Anda untuk menemukan sendiri.


1
Saya ingin tahu apakah kebocoran ada hubungannya dengan "coding perahu"?

0

FWIW, jika pengguna melaporkan kebocoran pada aplikasi yang saya kerjakan, saya akan sangat cenderung memperbaikinya (terutama jika mereka memasukkan kode untuk perbaikan dalam laporan bug!). Yang mengatakan, itu mungkin tidak terjadi segera jika kebocoran kecil dan masalah lainnya lebih mendesak (katakanlah, bug menabrak yang sering terjadi). Tapi saya pasti akan menghargai itu dan bekerja untuk memperbaikinya pada akhirnya. Anda harus memberi tahu mereka. Mereka akan menghargainya dan bekerja untuk memperbaikinya (kemungkinan besar), atau mereka tidak akan peduli dan semua itu akan menghabiskan waktu Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.