Când lucrezi cu drivere, module sau patch-uri de kernel, o scurgere de memorie nu înseamnă doar „RAM pierdut”. Înseamnă instabilitate greu de reprodus, comportament imprevizibil după ore de funcționare și buguri care apar exact când sistemul este sub presiune. În Linux, unul dintre instrumentele utile pentru investigarea acestor probleme este kmemleak, detectorul de posibile memory leaks din kernel.
Important este cuvântul „posibile”. Kmemleak nu este un verdict juridic asupra codului tău. Este un sistem de detecție care indică obiecte alocate pe care nu le mai găsește ca fiind referențiate. Uneori, asta înseamnă o scurgere reală. Alteori, poate fi un false positive care trebuie analizat cu atenție.
Cum funcționează kmemleak, pe scurt
Documentația oficială a kernelului descrie kmemleak ca pe un mecanism asemănător unui tracing garbage collector. Diferența esențială este că obiectele considerate „orfane” nu sunt eliberate automat. Ele sunt doar raportate prin interfața /sys/kernel/debug/kmemleak, astfel încât dezvoltatorul să investigheze cauza.
Pentru a-l folosi, kernelul trebuie construit cu opțiunea CONFIG_DEBUG_KMEMLEAK activată în zona „Kernel hacking”. În mod implicit, un thread al kernelului scanează memoria la fiecare 10 minute. Dacă debugfs nu este montat, interfața poate fi făcută disponibilă prin montarea debugfs în /sys/kernel/debug.
Comenzile de bază sunt simple: citești raportul din /sys/kernel/debug/kmemleak, declanșezi manual o scanare cu „scan” și cureți lista curentă de suspiciuni cu „clear”. Kmemleak mai permite oprirea scanării automate, modificarea perioadei de scanare, activarea sau dezactivarea scanării stivelor și inspectarea unui obiect prin dump pe adresă.
De ce apar raportările
Kmemleak urmărește alocări făcute prin familii de funcții precum kmalloc, vmalloc și kmem_cache_alloc, apoi păstrează informații despre adresă, dimensiune și stack trace. La eliberare, obiectul este scos din structurile interne ale kmemleak.
În timpul scanării, algoritmul marchează obiectele ca „white”, scanează zone precum secțiunea de date și stivele, caută valori care arată ca pointeri către obiecte alocate și mută obiectele găsite într-o stare „gray”. La final, obiectele care rămân „white” sunt considerate orfane și apar în raport.
Aici apare prima capcană: kmemleak caută dovezi că un obiect mai este referențiat. Dacă pointerul există într-o formă pe care scanarea nu o poate interpreta sigur, obiectul poate fi raportat chiar dacă în practică încă este accesibil. De aceea, raportul trebuie citit ca indiciu tehnic, nu ca dovadă absolută.
Cum testezi curat o zonă suspectă
În dezvoltarea de kernel, baseline-ul contează. Dacă pornești de la un raport deja plin de suspiciuni, riști să urmărești urme vechi, nu bugul pe care tocmai l-ai introdus. Documentația recomandă o abordare simplă pentru testarea unei secțiuni: cureți lista curentă, rulezi codul sau modulul pe care vrei să-l verifici, declanșezi o scanare și apoi citești raportul.
Practic, ordinea sănătoasă este: clear înainte de test, execuția scenariului, scan manual, apoi citirea kmemleak. Pentru rezultate mai solide, repetă scenariul. O scurgere reală tinde să reapară în același loc, cu stack trace similar și cu o legătură clară cu operația testată. Un false positive poate fi instabil, dependent de timing sau legat de obiecte care au încă un proprietar valid în ciclul de viață al subsistemului.
Cum separi o scurgere reală de un false positive
Primul semn al unei scurgeri reale este reproducibilitatea. Dacă același obiect sau același traseu de alocare apare după fiecare încărcare, folosire și descărcare a unui modul, investigația trebuie tratată serios. Verifică stack trace-ul, calea de eroare, ramurile de cleanup și simetria dintre alocare și eliberare.
Al doilea semn este acumularea. Dacă numărul de obiecte suspecte crește după fiecare rulare a aceluiași test, ai un indiciu mai puternic decât o singură raportare izolată. În schimb, o intrare unică, apărută după boot sau înainte de curățarea baseline-ului, poate fi zgomot de fond.
Al treilea criteriu este ciclul de viață. Unele obiecte sunt intenționat păstrate cât timp subsistemul este activ sau cât timp modulul rămâne încărcat. Dacă raportul dispare după oprirea componentei sau după cleanup-ul corect, nu ai neapărat o scurgere. Dacă rămâne după ce obiectul ar fi trebuit eliberat, suspiciunea devine mult mai serioasă.
Mai trebuie ținut cont de un detaliu din documentație: un obiect raportat la începutul listei poate face ca obiecte ulterioare să pară și ele orfane. De aceea, nu trata fiecare linie ca bug separat. Începe cu prima alocare relevantă și urmărește lanțul de dependențe.
Concluzie practică
Kmemleak este valoros tocmai pentru că nu promite magie. Îți oferă un semnal tehnic despre obiecte pe care kernelul nu le mai vede ca fiind referențiate, iar tu trebuie să faci partea de inginerie: test izolat, scanări repetate, citirea stack trace-ului și verificarea logicii de cleanup.
Pentru dezvoltatorii Linux avansați, diferența dintre un bug real și un false positive nu stă într-o singură comandă, ci în disciplină: pornești de la un baseline curat, reproduci scenariul, cauți acumulare și corelezi raportul cu ciclul de viață al obiectului. Așa transformi kmemleak dintr-o listă de alarme într-un instrument precis de depanare.
