Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Speicherleck aus getaddrinfo()
Hi zusammen,
wenn ihr eure Implementierung der snail mit [m]valgrind --leak-check=full[/m] testet (und die Erinnerung: das solltet ihr bei jeder Aufgabe tun! 
), stoßt ihr im CIP wahrscheinlich auf ungefähr folgende Ausgabe:
==30432== 28 bytes in 1 blocks are definitely lost in loss record 1 of 1
==30432== at 0x4C28C20: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30432== by 0x4F3AF49: __res_vinit (res_init.c:317)
==30432== by 0x4F3C3A4: __res_maybe_init (res_libc.c:125)
==30432== by 0x4F08A07: gaih_inet (getaddrinfo.c:827)
==30432== by 0x4F0A85C: getaddrinfo (getaddrinfo.c:2426)
==30432== by 0x400D09: getHostFqdn (snail.c:23)
==30432== by 0x400D09: main (snail.c:136)Dieses Problem ist leider ein Bug in der im CIP eingesetzten libc-Version (der passende Bugreport ist dieser hier: https://lists.debian.org/debian-glibc/2016/03/msg00243.html), und kann von euch nicht behoben werden.
Wenn ihr sonst keine Speicherlecks habt, passt zumindest schon mal die Speicherverwaltung in eurer snail 
Naja, gewisse solche Dinge sind nichtmal Bugs in den Bibliotheken sondern “false positives” die valgrind nicht unterdrueckt. Siehe auch /usr/lib/valgrind/default.supp und /usr/lib/valgrind/debian.supp fuer eine recht lange Liste von Dingen ueber die Valgrind erst garnicht jammert.
Ein kleines Update:
Die CIP-Admins haben eine suppression (und zwar diese hier: 0) für diesen Bug eingebaut, d.h. das CIP-valgrind sollte den verlorenen Speicher jetzt statt unter “definitely lost” unter “suppressed” einordnen.
==20116== LEAK SUMMARY:
==20116== definitely lost: 0 bytes in 0 blocks
==20116== indirectly lost: 0 bytes in 0 blocks
==20116== possibly lost: 0 bytes in 0 blocks
==20116== still reachable: 0 bytes in 0 blocks
==20116== suppressed: 28 bytes in 1 blocks