Çalışan bir işlemin bellek sızıntısını nasıl bulabilirim?

Çalışan bir işlemin bellek sızıntısını bulabilir miyim? Bir işlem başlamadan önce bellek sızıntılarını bulmak için Valgrind'i kullanabilirim. GDB'yi çalışan bir sürece eklemek için kullanabilirim. Çalışan bir işlemin bellek sızıntılarında nasıl hata ayıklayabilirim?

İşte hafızayı kimin sızdırdığını bulmak için neredeyse garanti adımları:

1. Bellek sızıntısına neden olan işlemin PID'sini öğrenin.

   ps -aux

2. yakalamak /proc/PID/smapsve gibi bir dosyaya kaydedin BeforeMemInc.txt.

3. bellek artana kadar bekleyin.
4. tekrar yakala /proc/PID/smapsve kaydetafterMemInc.txt

5. birinci smapsve ikinci arasındaki farkı bulun smaps, örneğin

   diff -u beforeMemInc.txt afterMemInc.txt

6. belleğin arttığı adres aralığını not edin, örneğin:

      beforeMemInc.txt            afterMemInc.txt
   ---------------------------------------------------
   2b3289290000-2b3289343000   2b3289290000-2b3289343000  #ADDRESS
   Shared_Clean:    0 kB       Shared_Clean:    0 kB          
   Shared_Dirty:    0 kB       Shared_Dirty:    0 kB
   Private_Clean:   0 kB       Private_Clean:   0 kB
   Private_Dirty:  28 kB       Private_Dirty:  36 kB  
   Referenced:     28 kB       Referenced:     36 kB
   Anonymous:      28 kB       Anonymous:      36 kB  #INCREASE MEM
   AnonHugePages:   0 kB       AnonHugePages:   0 kB
   Swap:            0 kB       Swap:            0 kB
   KernelPageSize:  4 kB       KernelPageSize:  4 kB
   MMUPageSize:     4 kB       MMUPageSize:     4 kB
   Locked:          0 kB       Locked:          0 kB
   VmFlags: rd wr mr mw me ac  VmFlags: rd wr mr mw me ac

7. çalışan işlemde bellek dökümü için GDB kullanın veya kullanarak coredump almak gcore -o process

8. Hafıza bir dosyaya dökümü için çalışan gdb kullandım.

   gdb -p PID
   dump memory ./dump_outputfile.dump 0x2b3289290000 0x2b3289343000

9. Şimdi, kullanım stringskomutu veya hexdump -Cyazdırmak içindump_outputfile.dump

   strings outputfile.dump

10. Bu dizeleri kaynak kodunuzda bulabileceğiniz okunabilir bir form alırsınız.

11. Sızıntıyı bulmak için kaynağınızı analiz edin.

Memleax tam olarak ne istediğinizi düşünüyorum .

Çalışan bir işlemin bellek sızıntısını, programı yeniden derlemeden veya hedef işlemi yeniden başlatmadan ekleyerek hata ayıklar. Üretim ortamı için çok uygun ve uygundur.

GNU / Linux ve FreeBSD üzerinde çalışır.

NOT: Ben yazarım, herhangi bir öneri bekliyoruz

== DÜZENLE ==

LD_PRELOAD'ın bellek fonksiyonlarını bağlayan başka bir araç libleak'i yazıyorum .

Hedef programı değiştirmeye de gerek yoktur. İlerlemeyi LD_PRELOAD ile yeniden başlatmanız gerekse de, çalıştırma sırasında algılamayı etkinleştirebilir / devre dışı bırakabilirsiniz.

Sinyal tuzağı olmadığından performans üzerinde çok daha az etki vardır.

Benzer araçlarla (mtrace gibi) karşılaştırıldığında, tam çağrı yığınını şüpheli bellek sızıntı noktasına yazdırır.

Linux'ta, mtrace'ı programınızda etkinleştirebilirsiniz , ancak bu bir kod değişikliğidir.

OpenBSD'de malloc istatistiklerini deneyebilirsiniz .

Google'ın sızıntı denetleyicisi de bir göz atmaya değer olabilir ve mtrace'den farklı olarak, LD_PRELOADyeniden derlemeyi önlemek için kullanabilirsiniz .

Programın doğrudan kaynak kodunda başlamasından sonra tahsis izlemesi için destek sağlamadan şanssızsınız. Düşünebilmem için iki neden var:

• Yığın denetleyicileri program başladığında başlatılır. Bazıları tam zamanlamayı ayarlama yeteneğini sunar, ancak bunları başlatan ortam değişkenleri program çalıştırıldığında ayarlanmalıdır. Bunun nedeni, her bir tahsisatın karşılık gelen bir yeniden konumlandırmaya sahip olmasını sağlamak için izlemeleri ve aksi takdirde bazılarını kaçırmalarıdır.
• Yığın denetimi genellikle işletim sistemi tarafından yükseltilmiş ayrıcalıklar veya kancalar gerektirir. Bu kancalar program başlangıcında sağlanmazsa, yığın denetleyicileri bunlardan yararlanamaz. OS'lerin söz konusu program başladıktan sonra bu ayrıcalıkları sağladığına inanmıyorum.

Ancak, programınız sanal bir makinenin içinde çalışıyorsa, bu ortam ayırmaların izlenmesi için destek sağlayabilir. Java'nın çalışan programlara veya VM'lere bağlanan birkaç ayırma ve çöp toplama izleme aracı ( visualVM gibi ) olduğunu biliyorum .

IBM'in Purify muhtemelen en eski ve en gelişmiş aracıdır. Bellek sızıntısına neden olan koddaki satır numarasını işaretler.