(Yönetilmeyen) kodunuzdaki Bellek sızıntılarını nasıl tespit eder / önlersiniz? [kapalı]

Yönetilmeyen C / C ++ kodunda, bellek sızıntılarını tespit etmek için en iyi uygulamalar nelerdir? Ve kaçınılması gereken kodlama yönergeleri? (Sanki bu kadar basitmiş gibi;)

Geçmişte biraz aptalca bir yol kullandık: her bellek ayırma çağrısı için bir sayaç artışına sahip olmak ve serbest bırakırken azaltma. Programın sonunda sayaç değeri sıfır olmalıdır.

Bunun harika bir yol olmadığını ve birkaç engel olduğunu biliyorum. (Örneğin, bir platform API çağrısı tarafından ayrılan belleği serbest bırakıyorsanız, ayırma sayınız boş bırakma sayınızla tam olarak eşleşmeyecektir. Elbette, o zaman belleği ayıran API çağrılarını çağırırken sayacı artırdık.)

Deneyimlerinizi, önerilerinizi ve belki bunu basitleştiren araçlara bazı referanslarınızı bekliyorum.

C / C ++ kodunuz * nix'e taşınabilirse, birkaç şey Valgrind'den daha iyidir .

Visual Studio kullanıyorsanız, Microsoft, bellek sızıntılarını algılamak ve hata ayıklamak için bazı yararlı işlevler sağlar.

Bu makaleyle başlayabilirim: https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx

İşte bu makalelerin hızlı özeti. İlk olarak, şu başlıkları ekleyin:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

O zaman programınız kapandığında bunu aramanız gerekir:

_CrtDumpMemoryLeaks();

Alternatif olarak, programınız her seferinde aynı yerden çıkmıyorsa, bunu programınızın başlangıcında arayabilirsiniz:

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

Artık program serbest bırakılmamış tüm tahsislerden çıktığında, tahsis edildikleri dosya ve tahsis oluşumu ile birlikte Çıktı Penceresinde yazdırılacaktır.

Bu strateji çoğu program için işe yarar. Ancak, bazı durumlarda zor veya imkansız hale gelir. Başlangıçta bir miktar başlatma yapan üçüncü taraf kitaplıklarının kullanılması, bellek dökümünde diğer nesnelerin görünmesine neden olabilir ve sızıntılarınızın izlenmesini zorlaştırabilir. Ayrıca, sınıflarınızdan herhangi birinin bellek ayırma yordamlarından herhangi biriyle (malloc gibi) aynı ada sahip üyeleri varsa, CRT hata ayıklama makroları sorunlara neden olur.

Yukarıda atıfta bulunulan MSDN bağlantısında da kullanılabilecek başka teknikler de vardır.

C ++ 'da: RAII kullanın. Akıllı işaretçiler gibi std::unique_ptr, std::shared_ptr, std::weak_ptrsizin dostunuz.

Bir C ++ Geliştirici olarak işte bazı basit yönergeler:

1. İşaretçileri yalnızca kesinlikle gerekli olduğunda kullanın
2. Bir işaretçiye ihtiyacınız varsa, bir SmartPointer'ın bir olasılık olup olmadığını iki kez kontrol edin.
3. GRASP Oluşturucu modelini kullanın .

Kişisel olarak bellek sızıntılarının tespiti konusunda, her zaman Görsel Sızıntı Dedektörü kullandım ve çok faydalı buldum.

DevStudio'yu çok uzun yıllardır kullanıyorum ve hata ayıklama çalışma zamanı kitaplıklarında bulunan bellek analizi araçları hakkında kaç programcının bilmediği beni her zaman şaşırtıyor. İşte başlamak için birkaç bağlantı:

Yığın Tahsis Taleplerini İzleme - özellikle Eşsiz Tahsis Talep Numaraları bölümü

_CrtSetDbgFlag

_CrtSetBreakAlloc

Elbette DevStudio kullanmıyorsanız, bu özellikle yardımcı olmayacaktır.

Windows işletim sistemi için DebugDiag'den kimsenin bahsetmediğine şaşırdım .
Sürüm yapıları üzerinde ve hatta müşteri sitesinde çalışır.
(Yalnızca sürüm PDB'lerinizi tutmanız ve DebugDiag'i Microsoft genel sembol sunucusunu kullanacak şekilde yapılandırmanız gerekir)

Visual Leak Detector, VC9 çalışma zamanlarında (örneğin MSVCR90D.DLL) çağrıları desteklemese de çok iyi bir araçtır.

Hata ayıklama modunda Microsoft VC ++, sızıntılarınızın nerede olduğunu göstermese de bellek sızıntılarını gösterir.

Eğer C ++ kullanıyorsanız her zaman yeni açıkça kullanılarak önleyebilirsiniz: Sahip vector, string, auto_ptr(C ++ 11 ön; yerini unique_ptrC ++ 11), unique_ptr(C ++ 11) veshared_ptr (C ++ 11) cephanelik.

Yeni kaçınılmaz olduğunda, onu bir yapıcıda gizlemeyi deneyin (ve bir yıkıcıda silmeyi gizleyin); aynı durum 3. parti API'ler için de geçerlidir.

Sonunda bir işlevi çağırmanıza izin verecek çeşitli yedek "malloc" kitaplıkları var ve size tüm serbest bırakılmamış bellek hakkında bilgi verecek ve çoğu durumda, onu kimin mallocladığını (veya yenisini) ilk etapta .

MS VC ++ kullanıyorsanız, bu ücretsiz aracı codeproject: leakfinder'dan şiddetle tavsiye edebilirim. by Jochen Kalmbach.

Sınıfı projenize eklemeniz ve

InitAllocCheck(ACOutput_XML)
DeInitAllocCheck()

sızıntıları kontrol etmek istediğiniz koddan önce ve sonra.

Kodu oluşturup çalıştırdıktan sonra Jochen, ortaya çıkan .xmlleaks dosyasını yükleyebileceğiniz ve rahatsız edici kod satırını bulmak için her sızıntının üretildiği çağrı yığınında gezinebileceğiniz temiz bir GUI aracı sağlar.

Rational's (şimdi IBM'e ait) PurifyPlus, sızıntıları benzer bir şekilde gösteriyor, ancak sızıntı bulucu aracının kullanımı aslında daha kolay buluyorum, bonus birkaç bin dolara mal olmuyor!

Kendim hiç kullanmadım, ama C arkadaşlarım bana Purify diyor .

Visual Studio kullanıyorsanız, Bounds Checker'a bakmaya değer olabilir . Ücretsiz değil, ancak kodumdaki sızıntıları bulmamda inanılmaz derecede yardımcı oldu. Sadece bellek sızıntıları da değil, aynı zamanda GDI kaynak sızıntıları, WinAPI kullanım hataları ve diğer şeyler de yapıyor. Sızan belleğin nerede başlatıldığını bile göstererek sızıntıyı takip etmeyi çok daha kolay hale getirir.

Bu sorunun kolay bir cevabı olmadığını düşünüyorum. Bu çözüme gerçekten nasıl yaklaşabileceğiniz, gereksinimlerinize bağlıdır. Çapraz platform çözümüne mi ihtiyacınız var? Yeni / sil veya malloc / ücretsiz (veya her ikisini birden) mi kullanıyorsunuz? Gerçekten sadece "sızıntıları" mı arıyorsunuz yoksa arabellek taşmalarını (veya yetersiz çalıştırmaları) tespit etmek gibi daha iyi koruma mı istiyorsunuz?

Windows tarafında çalışıyorsanız, MS hata ayıklama çalışma zamanı kitaplıkları bazı temel hata ayıklama algılama işlevlerine sahiptir ve bir başkasının daha önce de belirttiği gibi, sızıntı tespitine yardımcı olmak için kaynağınıza dahil edilebilecek birkaç sarmalayıcı vardır. Hem new / delete hem de malloc / free ile çalışabilen bir paket bulmak açıkçası size daha fazla esneklik sağlar.

Unix tarafı hakkında yardım sağlayacak kadar bilgim yok, ancak yine de diğerleri var.

Ancak kaçak tespitinin ötesinde, arabellek taşmaları (veya yetersiz çalıştırmalar) yoluyla bellek bozulmasını algılama kavramı vardır. Bu tür bir hata ayıklama işlevi bence düz sızıntı tespitinden daha zor. Bu tür bir sistem, C ++ nesneleriyle çalışıyorsanız daha da karmaşık hale gelir çünkü polimorfik sınıflar, silinmekte olan gerçek temel işaretçiyi belirlemede yanıltıcılığa neden olan çeşitli şekillerde silinebilir. Taşmalar için yeterli koruma sağlayan iyi bir "özgür" sistem bilmiyorum. bir sistem (çapraz platform) yazdık ve bunu oldukça zor bulduk.

Geçmişte kullandığım bir şeyi sunmak istiyorum: kaynak düzeyinde ve oldukça otomatik olan temel bir sızıntı denetleyicisi. Bunu üç nedenden ötürü veriyorum:

1. Yararlı bulabilirsin.

2. Biraz zor olsa da, bunun beni utandırmasına izin vermem.

3. Bazı win32 kancalarına bağlı olsa bile, bunu hafifletmesi kolay olmalı.

Kullanırken dikkatli olmanız gereken şeyler var: dayanmanız gereken hiçbir şey yapmayın new temel koda yapmayın, leakcheck.cpp'nin üst kısmında gözden kaçırabileceği durumlar hakkındaki uyarılara dikkat edin, dönerseniz fark edin. görüntü dökümü yapan kod üzerinde (ve bu kodla ilgili sorunları giderirseniz) çok büyük bir dosya oluşturabilirsiniz.

Tasarım, başlığını içeren her şeyi yeniden derlemeden denetleyiciyi açıp kapatmanıza izin vermek içindir. Sızıntıcheck.h dosyasını kontrol etmek ve bir kez yeniden oluşturmak istediğiniz yere ekleyin. Daha sonra, LEAKCHECK # ile veya olmadan leakcheck.cpp derleyin ve ardından onu açıp kapatmak için yeniden bağlayın. Unleakcheck.h dahil edildiğinde bir dosyada yerel olarak kapatılır. İki makro sağlanmıştır: CLEARALLOCINFO (), leakcheck.h içermeyen ayırma kodunu geçtiğinizde aynı dosyayı ve satırı uygunsuz bir şekilde bildirmekten kaçınacaktır. ALLOCFENCE (), herhangi bir tahsisat yapmadan oluşturulan raporda sadece bir satır bırakır.

Yine, lütfen bunu bir süredir kullanmadığımı ve onunla biraz çalışmanız gerekebileceğini unutmayın. Fikri açıklamak için onu bırakıyorum. Yeterli ilgi olduğu ortaya çıkarsa, bir örnek oluşturmaya, işlemdeki kodu güncellemeye ve aşağıdaki URL'nin içeriğini düzgün bir şekilde sözdizimi renginde bir liste içeren daha hoş bir şeyle değiştirmeye istekli olacağım.

Burada bulabilirsiniz: http://www.cse.ucsd.edu/~tkammeye/leakcheck.html

Linux için: Google Perftools'u deneyin

Benzer ayırma / ücretsiz sayma yapan birçok araç var, Goolge Perftools'un artıları:

• Oldukça hızlı (valgrind ile karşılaştırıldığında: çok hızlı)
• Sonuçların güzel grafik görüntüsü ile birlikte gelir
• Başka yararlı yeteneklere sahiptir: cpu profili oluşturma, bellek kullanım profili oluşturma ...

Sızıntılara karşı en iyi savunma, malloc kullanımını en aza indiren bir program yapısıdır. Bu sadece programlama açısından iyi değil, aynı zamanda performansı ve sürdürülebilirliği de geliştiriyor. Malloc yerine başka şeyler kullanmaktan bahsetmiyorum, ancak çöp toplayıcıları olan dillerde sık sık alıştığı gibi istemsizce ayırmak yerine nesneleri yeniden kullanmak ve etrafta dolaşan tüm nesnelerde çok açık sekmeler tutmak açısından Java gibi.

Örneğin, üzerinde çalıştığım bir programda görüntü verilerini temsil eden bir dizi çerçeve nesnesi var. Her çerçeve nesnesi, çerçevenin yıkıcısının serbest bıraktığı alt verilere sahiptir. Program, tahsis edilen tüm çerçevelerin bir listesini tutar ve yenisine ihtiyaç duyduğunda, yeni bir çerçeve tahsis etmek yerine mevcut olanı yeniden kullanıp kullanamayacağını görmek için kullanılmayan çerçeve nesnelerinin bir listesini kontrol eder. Kapandığında, her şeyi serbest bırakarak yalnızca listeyi yineler.

Yazılım doğrulamasından Memory Validator'ı kullanmanızı tavsiye ederim . Bu araç, bellek sızıntılarını izlememe ve üzerinde çalıştığım uygulamaların bellek yönetimini iyileştirmeme yardımcı olacak paha biçilmez bir yardım olduğunu kanıtladı.

Çok eksiksiz ve hızlı bir araç.

Çağrıları kaydeden ve ardından çağrıyı gerçek işleve geçiren kendi sistem çağrı işlevlerinizi enterpolasyon yaparak tüm bildirimleri ve serbestleri sayıyor musunuz?

Yazmadığınız koddan kaynaklanan aramaları takip etmenin tek yolu budur.

Ld.so için man sayfasına bir göz atın. Veya bazı sistemlerde ld.so.1.

Ayrıca Google LD_PRELOAD yapın ve www.itworld.com adresinde tekniği açıklayan bazı ilginç makaleler bulacaksınız.

En azından MS VC ++ için, C Runtime kitaplığının geçmişte yararlı bulduğum birkaç işlevi vardır. _Crt*İşlevler için MSDN yardımına bakın .

Paul Nettle'ın mmgr'si uzun zamandır en sevdiğim aletim . Mmgr.h dosyasını kaynak dosyalarınıza eklersiniz, TEST_MEMORY tanımlarsınız ve uygulamanızın çalıştırılması sırasında oluşan bellek sorunları ile dolu bir metin dosyası sunar.

Genel Kodlama Rehberi:

• Kaynaklar, tahsis edildikleri aynı "katmanda" (işlev / sınıf / kitaplık) serbest bırakılmalıdır.
• Bu mümkün değilse, bazı otomatik ayırmayı kaldırmayı deneyin (paylaşılan işaretçiyi artırın ...)

Bellek hata ayıklama araçları ağırlıkları altın değerindedir, ancak yıllar geçtikçe bellek / kaynak sızıntılarının çoğunun ilk etapta kodlanmasını önlemek için iki basit fikrin kullanılabileceğini keşfettim.

1. Tahsis etmek istediğiniz kaynaklar için edinim kodunu yazdıktan hemen sonra yayın kodunu yazın. Bu yöntemle "unutmak" daha zordur ve bir bakıma, kaynakların yaşam döngüsünün bir kenara değil, önceden kullanılmasını ciddi olarak düşünmeye zorlar.

2. İade işlemini mümkün olduğunca tartışmalı kullanın. Tahsis edilenler, mümkünse yalnızca bir yerde serbest bırakılmalıdır. Kaynak edinme ve serbest bırakma arasındaki koşullu yol, olabildiğince basit ve açık olacak şekilde tasarlanmalıdır.

Bu listenin başında (okuduğumda) valgrind vardı. Bir test sisteminde sızıntıyı yeniden oluşturabiliyorsanız Valgrind mükemmeldir. Onu büyük bir başarıyla kullandım.

Ya üretim sisteminin şu anda sızdırdığını fark ettiyseniz ve bunu testte nasıl yeniden üreteceğiniz konusunda hiçbir fikriniz yoksa? Bu üretim sistemi durumunda neyin yanlış olduğuna dair bazı kanıtlar yakalanır ve sorunu yeniden üretebilmeniz için sorunun nerede olduğuna dair bir fikir vermek yeterli olabilir.

Monte Carlo örneklemesi burada devreye giriyor. Raymond Chen'in "Zavallı adamın bellek sızıntılarını tanımlama yöntemi" adlı blog makalesini okuyun ve ardından uygulamama göz atın (Linux varsayar, yalnızca x86 ve x86-64'te test edilmiştir)

http://github.com/tialaramex/leakdice/tree/master

Motorola cep telefonlarının işletim sistemi üzerinde çalışırken, tüm bellek ayırmalarını gözlemlemek için bellek ayırma kitaplığını ele geçirdik. Bellek ayırmalarıyla ilgili birçok sorun bulmaya yardımcı oldu. Önleme, iyileştirmeden daha iyi olduğu için, Klockwork veya PC-Lint gibi statik analiz araçlarını kullanmanızı tavsiye ederim.

Valgrind, Linux için güzel bir seçenektir. MacOS X altında, bellek ayırma problemlerinde hata ayıklamak için çeşitli seçeneklere sahip MallocDebug kütüphanesini etkinleştirebilirsiniz (malloc kılavuzuna bakın, "ÇEVRE" bölümünde ilgili ayrıntılar yer almaktadır). OS X SDK ayrıca, kullanımı ve sızıntıları izlemenize yardımcı olabilecek MallocDebug adında bir araç içerir (genellikle / Developer / Applications / Performance Tools / içine yüklenir).

Algılama:

CRT'de hata ayıklama

Önlemek:

Akıllı işaretçiler, boehm GC

Güzel bir malloc, calloc ve reallloc değişimi rmdebug'dur, kullanımı oldukça basittir. Bundan sonra valgrind çok daha hızlıdır, böylece kodunuzu kapsamlı bir şekilde test edebilirsiniz. Elbette bazı dezavantajları var, bir sızıntı bulduğunuzda, sızıntının nerede göründüğünü bulmak için muhtemelen valgrind kullanmanız gerekir ve yalnızca doğrudan yaptığınız malloc'ları test edebilirsiniz. Eğer bir kitaplık yanlış kullandığınız için sızarsa, rmdebug onu bulamaz.

http://www.hexco.de/rmdebug/

Bellek profil oluşturucuların çoğu, büyük karmaşık Windows uygulamamı, sonuçların yararsız olduğu noktaya kadar yavaşlatır. Uygulamamdaki sızıntıları bulmak için iyi çalışan bir araç var: UMDH - http://msdn.microsoft.com/en-us/library/ff560206%28VS.85%29.aspx

Mtrace , linux için standart yerleşik olan gibi görünüyor. Adımlar:

1. bash
   MALLOC_TRACE = / tmp / mtrace.dat export MALLOC_TRACE ortam değişkenini
   MALLOC_TRACE;
2. Ana kaynak dosyanızın en üstüne #include <mcheck.h> ekleyin
3. Ekle Mtrace () ; main ve muntrace'in başlangıcında ();altta (dönüş ifadesinden önce)
4. programınızı hata ayıklama bilgileri için -g anahtarıyla derleyin
5. programını çalıştır
6. 
   mtrace your_prog_exe_name /tmp/mtrace.dat ile sızıntı bilgilerini göster
   ( yum install glibc_utils ile fedora sistemime önce mtrace perl betiğini kurmam gerekiyordu   )