Când o aplicație Linux începe să consume tot mai mult RAM, primul impuls este adesea să o repornești. Problema reală este că repornirea ascunde simptomele, nu cauza. Un memory leak înseamnă memorie alocată și neeliberată, dar în teren poți întâlni și alte situații care seamănă cu un leak: cache intern care crește intenționat, fragmentare, memorie „still reachable” la ieșirea procesului sau vârfuri de consum care nu indică o scurgere propriu-zisă. De aceea, diagnosticul corect combină trei perspective: Valgrind pentru erori clasice de memorie, heap profiling pentru evoluția consumului în timp și core dumps pentru analiza post-mortem.
Primul pas este să pregătești corect binarul pentru investigație. Ghidul oficial Valgrind recomandă compilarea cu simboluri de depanare, de exemplu cu -g, pentru ca rapoartele să includă linii și funcții utile. În cazul Memcheck, optimizările agresive nu sunt ideale, pentru că pot face stack trace-urile mai greu de citit. Asta contează mai ales la aplicații C și C++, unde diferența dintre un backtrace clar și unul incomplet poate însemna ore întregi de muncă în plus.
Pentru leak-uri clasice, punctul de plecare rămâne Valgrind Memcheck. Într-un mediu de test, o rulare tipică este valgrind –leak-check=full –show-leak-kinds=all ./aplicatia_ta. Documentația oficială avertizează că programul poate rula de 20–30 de ori mai lent sub Memcheck și poate consuma semnificativ mai multă memorie, deci nu vorbim despre o unealtă pentru producție. Ce urmărești în raport? „Definitely lost” este semnalul cel mai clar că ai memorie pierdută. „Possibly lost” cere verificări suplimentare, iar „still reachable” nu este automat un bug; poate fi memorie păstrată până la terminarea procesului de biblioteci, allocatoare sau runtime. Dacă întâlnești mesaje despre valori neinițializate, opțiunea –track-origins=yes poate ajuta să găsești sursa, chiar dacă încetinește și mai mult execuția.
Totuși, nu toate problemele apar ca leak-uri clasice la finalul procesului. Dacă aplicația nu cade, dar crește treptat în memorie pe parcursul orelor sau zilelor, heap profiling-ul este adesea mai util decât un leak check punctual. În ecosistemul Valgrind, Massif măsoară utilizarea heap-ului și scrie datele în fișiere de tip massif.out., care apoi pot fi citite cu ms_print. Avantajul este clar: vezi curba consumului și punctul de vârf, împreună cu stack-urile care au generat alocările. Manualul Massif subliniază și un lucru important pentru producție și servere: poate scoate la lumină așa-numitele „space leaks”, adică memorie care încă are pointeri valizi, dar continuă să ocupe RAM fără să mai aducă valoare aplicației.
Pentru aplicațiile construite cu gperftools sau tcmalloc, heap profiling-ul oferă un alt traseu util de analiză. Documentația oficială arată că profilarea se activează prin variabila de mediu HEAPPROFILE, iar rezultatele se analizează cu pprof. Aici devine valoroasă comparația dintre profile. Cu opțiunea –base, poți compara un profil mai târziu cu unul de referință și vezi ce s-a acumulat între două momente. În plus, pprof poate raporta atât memoria în uz, cât și numărul de obiecte în uz, ceea ce ajută când problema vine din foarte multe alocări mici, nu doar din câteva blocuri mari.
Core dump-urile devin esențiale când aplicația se prăbușește sau când ai nevoie de o fotografie exactă a stării procesului. Pagina core(5) explică de ce un dump poate lipsi chiar dacă procesul a murit: limita RLIMIT_CORE poate fi zero, directorul nu este inscriptibil, sistemul de fișiere poate fi plin sau kernel.core_pattern poate trimite ieșirea într-un alt flux. Pe sistemele moderne cu systemd, dump-urile sunt adesea gestionate de systemd-coredump, iar coredumpctl poate lista, inspecta și trimite dump-ul către debugger. Aici trebuie menționată o diferență importantă între distribuții și configurații: unele sisteme păstrează dump-urile în /var/lib/systemd/coredump, altele le rotesc, le trunchiază sau schimbă retenția prin coredump.conf și politicile locale.
Dacă vrei o captură fără să aștepți un crash, GDB oferă generate-core-file sau gcore pentru procesul investigat. Este util în laborator sau în staging, dar nu este o decizie de luat ușor pe sisteme sensibile. Un core dump poate conține secrete în memorie, date de sesiune sau informații personale, deci fișierele trebuie tratate ca artefacte sensibile și stocate controlat.
În practică, diagnosticul bun urmează o ordine simplă. Folosești Memcheck ca să confirmi leak-uri și erori clasice de alocare, Massif sau pprof ca să vezi cum evoluează memoria în timp și core dump-uri ca să înțelegi starea exactă a procesului la crash sau într-un moment ales. Combinând aceste trei unelte, ai șanse mult mai mari să găsești nu doar simptomul, ci funcția, biblioteca sau tiparul de execuție care provoacă problema.
Surse
- https://valgrind.org/docs/manual/QuickStart.html
- https://valgrind.org/docs/manual/FAQ.html
- https://valgrind.org/docs/manual/ms-manual.html
- https://gperftools.github.io/gperftools/heapprofile.html
- https://man7.org/linux/man-pages/man5/core.5.html
- https://man7.org/linux/man-pages/man1/coredumpctl.1.html
- https://www.freedesktop.org/software/systemd/man/latest/systemd-coredump.html
- https://sourceware.org/gdb/current/onlinedocs/gdb.html/Core-File-Generation.html
