On Fri, Nov 22, 2019 at 04:34:42PM +0100, Koen Vandeputte wrote: > Playing around with Valgrind and wpa_supplicant (v2.9 + IBSS + WPA2 PSK) > shows this on application closure: > > ==3005== 4 bytes in 1 blocks are still reachable in loss record 1 of 6 > ==3005== at 0x489582C: calloc (vg_replace_malloc.c:762) > ==3005== by 0x4037BBB: __getgrent_a (getgrent_a.c:46) > ==3005== by 0x403738F: __getgr_a (getgr_a.c:35) > ==3005== by 0x4037A47: getgrnam (getgrent.c:37) > ==3005== by 0x402B7: wpas_ctrl_iface_open_sock (in > /usr/sbin/wpa_supplicant) > ==3005== > ==3005== 12 bytes in 1 blocks are still reachable in loss record 2 of 6 > ==3005== at 0x4895A94: realloc (vg_replace_malloc.c:836) > ==3005== by 0x4045947: getdelim (getdelim.c:38) > ==3005== by 0x4037AA3: __getgrent_a (getgrent_a.c:20) > ==3005== by 0x403738F: __getgr_a (getgr_a.c:35) > ==3005== by 0x4037A47: getgrnam (getgrent.c:37) > ==3005== by 0x402B7: wpas_ctrl_iface_open_sock (in > /usr/sbin/wpa_supplicant) Those two look like C library memory "leaks" of temporary buffers that might be reused for multiple calls. getgrnam() is explicitly documented as allowing different types of memory buffers to be used and the caller not being allowed to free the returned value. As such, I don't think there is much, if anything, a user of getgrnam() with that particular C library could do. I don't see valgrind reporting memory leaks in my tests for this, but I think I've seen something similar in the past with older glibc versions. > ==3005== 56 bytes in 2 blocks are definitely lost in loss record 3 of 6 > ==3005== at 0x489582C: calloc (vg_replace_malloc.c:762) > ==3005== by 0x326F3: wpa_driver_nl80211_finish_drv_init.lto_priv.412 (in > /usr/sbin/wpa_supplicant) I'm not sure what this is pointing to. Anyway, I don't see that in my tests either. My first guess would be that this would also be one of the libraries triggering a memory leak. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
